IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Petit débat sur la conception d'API


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 127
    Points
    9 127
    Par défaut Petit débat sur la conception d'API
    Bonjour

    Suite à une discussion avec un collègue sur la "validité" d'un choix dans une définition d'une API, J'ouvre cette discussion.

    Je ne cherche pas à discuter des avantages ou des inconvénients de SOAP vs Rest vs GraphQL vs gRCP vs .....

    Il y a suffisamment de discussions, de pour et de contre, pour chaque technologie.

    Je cherche plutôt à avoir un débat qui permet à un développeur de faire son choix.

    Hors mis, les particularités d'implémentation on peut distinguer deux approches qui s'opposent ou semblent s'opposer.

    Les API définies autour des fonctions (SOAP et gRCP en font partie)
    Les API définies autour des données (Rest et GraphQL en font partie)

    Les premières relèvent de choses comme "calculerLeTauxDAmmortissement". Les secondes relèves de choses comme "Vehicules".

    Et entre les deux, il y a toutes les approches dites pragmatiques qui mixent avec plus ou moins de bonheur les deux.

    Ce qui est apparu dans la discussion est le fait que dans une solution dont l'essentiel est une API Rest, le besoin était d'exposer quelque chose qui relève d'une API fonctionnelle.

    Pour faire simple en première approche le choix a été de garder l'approche REST, mais sur quelques URL d'avoir
    http://monserveur/mon/api/faire/un/truc
    Et là effectivement, il ne s'agit pas d'une URL conforme à REST.

    Le problème est alors: comment répondre au besoin tout en restant conforme à REST ?
    (Je pense qu'il est assez facile de faire le pendant en partant d'une API fonctionnelle dans laquelle on se retrouve avec une partie qui est plutôt de la gestion de ressource.)

    Si l'on veut rester "strictement" conforme à une approche ressource alors c'est au client de faire le calcul

    GET /ma/resource/868686 =>r1
    faire un truc côté client avec r1
    PUT r1 /ma/resource/868686

    1er problème la ressource r1 peut être très grosse et complexe alors que faire un truc n'agit que sur une partie. GraphQL répond à ce genre de situation
    2e problème la concurrence si 2 clients demandent la même ressource, agissent en même temps de leur côté avant de poster la ressource modifiée, comment savoir laquelle des deux garder comment garantir la cohérence ?
    Là encore on peut imaginer des solutions comme répondre au second qui poste que la ressource a été modifiée et que son post n'est plus acceptable. Ou toute autre solution d'accès exclusif.
    3e problème: le truc a faire et beaucoup trop complexe pour être fait par le client. Là en restant "strictement" conforme à REST il n'y a pas de solution. Il faut que ce soit le serveur qui le fasse donc qu'il en reçoive l'ordre.

    Une autre limitation de REST est le principe selon lequel un GET ne peut agir sur la ressource un POST la crée et PUT et PATCH la modifie, et un DELETE la supprime.
    Pourtant nous avons de nombreux cas qui dérogent à ce principe.

    Ce sont tous les cas où on consomme des éléments par exemple.
    J'ai un carnet de tickets de cinéma à chaque fois que j'en prends un (GET) il est supprimé du carnet. Si on veut rester purement REST on fait un GET puis un DELETE
    en clair on fait confiance au client pour marquer qu'il a consommé un ticket ce qui n'est pas vraiment le but.

    De ce que je constate dans la majorité des API qui rencontre ce genre de difficultés, on déroge aux principes de base de REST pour entrer dans "une approche pragmatique".

    Je lance donc le débat si vous le voulez bien pour essayer de dégager des généralités sur ces cas qui dans une approche ressource nécessitent des "actions" ou dans une approche fonctionnelle demande des échanges de ressources. Ce dernier cas semble plus simple. Mais je ne veux pas fermer le débat.



    A+JYT

  2. #2
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 453
    Points : 6 027
    Points
    6 027
    Par défaut
    Bonjour,

    Si je résume, la problématique est de savoir si on met la logique métier côté client ou côté serveur. Si on la met côté client, alors le serveur joue un peu le même rôle qu'une base de données sans procédure stockée (avec beaucoup plus de restrictions, entre autres pour des raisons de cybersécurité).

    Cela me fait penser à un article de Michele Sollecito intitulé It's time to put REST to rest. L'auteur préfère que la logique métier soit côté serveur et propose que toutes les requêtes soient POST et suivent le format d'URL /commands/{command-type}/version/{command-version}.

    En pratique, si le code côté client et le code côté serveur sont gérés par des équipes différentes voire des entreprises différentes, alors la loi de Conway aura un fort impact.

Discussions similaires

  1. [OpenGL] Petite question sur l'API
    Par Fabien Henon dans le forum OpenGL
    Réponses: 7
    Dernier message: 17/01/2008, 00h27
  2. [C++] 2 petites questions sur l'API Windows
    Par Fabien Henon dans le forum Windows
    Réponses: 15
    Dernier message: 25/12/2007, 12h54
  3. Réponses: 3
    Dernier message: 11/06/2006, 13h09
  4. Réponses: 24
    Dernier message: 29/08/2005, 14h33
  5. Petite question sur les performances de Postgres ...
    Par cb44 dans le forum PostgreSQL
    Réponses: 5
    Dernier message: 13/01/2004, 14h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo