Discussion :

[sekaijin]

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

[Pyramidev]

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.