Il y a quelques bonnes réponses ici, mais je ne suis pas sûr qu'elles vous aideront à convaincre vos collègues. Comme beaucoup l'ont fait remarquer, ce que vous suggérez n'est pas un changement de conception RESTful, et je pense que c'est essentiel pour les intégrer à votre proposition.
REST ne consiste pas à s'assurer que votre API ne permet que le stockage et la récupération de données. Il s’agit plutôt de modéliser des actions en tant que ressources. Votre API doit permettre de prendre des mesures (c'est une interface de programmation d' application , après tout). La question est de savoir comment modéliser ces actions.
Plutôt que de proposer un terme, les exemples sont probablement la meilleure façon de l'expliquer à vos collègues . De cette façon, vous pouvez montrer comment ils le font maintenant, quels problèmes cela cause, une solution qui résout le problème et comment il reste toujours RESTful.
Regardons votre objet client.
Problème:
L’UI POST un client, mais les tables suivantes n’ont pas encore été mises à jour. Que se passe-t-il si l'un des appels suivants échoue en raison d'une erreur dans votre code d'interface utilisateur (ou d'un plug-in de navigateur qui se comporte mal, etc.)? Vos données sont maintenant dans un état incohérent. Il pourrait même s'agir d'un état qui casse d'autres parties de votre API ou de votre interface utilisateur, sans parler de son invalidité. Comment récupérez-vous? Vous devez tester tous les états possibles pour vous assurer que cela ne casse pas quelque chose, mais il serait difficile de savoir ce qui est possible.
Solution:
Créez un point de terminaison API pour créer des clients. Vous savez que vous ne voulez pas avoir de point de terminaison "/ customer / create" ou même "/ create-customer", car create est un verbe qui violerait REST. Alors, nommez-le. "/ customer-creation" pourrait fonctionner. Désormais, lorsque vous POSTerez votre objet CustomerCreation, il enverra tous les champs nécessaires à la création complète d'un client. Le noeud final s'assurera que les données sont complètes et valides (en renvoyant 400 ou quelque chose si la validation échoue), et peuvent persister dans une seule transaction de base de données, par exemple.
Si vous avez également besoin d'un point d'extrémité pour obtenir des objets GET / client, c'est très bien. Vous pouvez avoir les deux. L'astuce consiste à créer des terminaux qui répondent aux besoins des consommateurs.
Avantages:
- Vous garantissez que vous ne vous retrouverez pas dans un mauvais état
- Il est en fait plus facile pour les développeurs d’interface utilisateur s’ils ne doivent pas "connaître" la commande des demandes, les problèmes de validation, etc.
- Ce n'est pas aussi bavard qu'une API, ce qui réduit la latence des requêtes réseau
- Il est plus facile de tester et de conceptualiser des scénarios (les données manquantes ou mal formées dans l'interface utilisateur ne sont pas réparties entre les demandes, certaines pouvant échouer).
- Il permet une meilleure encapsulation de la logique métier
- Facilite généralement la sécurité (car les utilisateurs peuvent modifier la logique métier et d'orchestration de l'interface utilisateur)
- Réduira probablement la duplication logique (plus probable que vous ayez plus de 2 utilisateurs d'API que plus de 2 API donnant accès aux mêmes données)
- Toujours 100% RESTful
Désavantages:
- C'est potentiellement plus de travail pour le développeur backend (mais peut-être pas à long terme)
Il peut être difficile pour les gens de comprendre ce paradigme et ses atouts s’ils ne l’ont pas essayé. J'espère que vous pourrez les aider à voir en utilisant un exemple de votre propre code.
Mon expérience personnelle est qu'une fois que les développeurs de mon équipe ont commencé à mettre en œuvre cette stratégie, ils en ont presque immédiatement constaté les avantages.
Une étude plus approfondie:
Cet article de thinkworks m'a vraiment aidé à concevoir des actions de modélisation en tant qu'objets à l'aide d'exemples pratiques: https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling
Je suggérerais également de lire CQRS et Event Sourcing, car ils sont précisément concernés par ce type de problème (par exemple, divorcer votre API de la logique de persistance réelle). Je ne sais pas à quel point vos collègues seraient disposés à lire ce genre de chose, mais cela peut vous éclairer davantage et vous aider à leur expliquer.