REST et HATEOAS sont-ils une bonne architecture pour les services Web?

Si je comprends bien, REST a été formalisé par Roy Fielding comme un modèle descriptif de l'architecture du web. AFAIK Fielding n'a pas prétendu que REST était bon, il décrivait simplement l'architecture de facto du Web. Le web avait déjà prouvé à ce stade un énorme système hypertexte distribué réussi, donc ce type de validation REST comme une architecture réussie pour le domaine de l'hypermédia distribué principalement navigué et consommé par les humains.

Les services Web REST ont été créés en appliquant l'architecture REST aux API. Mais y a-t-il réellement une raison de penser que REST est une architecture souhaitable pour ce domaine? Plus précisément, existe-t-il des preuves que HATEOAS est un principe de conception bénéfique pour la communication de machine à machine?

Ma préoccupation est que HATEOAS a du sens pour l'hypermédia car il existe peu de types de contenu bien connus (HTML, images, vidéo, etc.) et le client sait comment les consommer. Mais pour les API, les types de contenu sont très spécifiques et ne peuvent être consommés de manière significative par le client que si le client est spécifiquement programmé pour les consommer. Le renvoi d'une URL au client ne permet pas en soi au client de consommer la ressource indiquée.

AFAIK Fielding n'a pas prétendu que REST était bon, il décrivait simplement l'architecture de facto du Web.

Je pense que cela le sous-estime un peu. REST est, après tout, une énumération du style architectural que Fielding utilisait comme architecte en chef de la spécification HTTP / 1.1 .

Mais y a-t-il réellement une raison de penser que REST est une architecture souhaitable pour ce domaine? Existe-t-il des preuves que HATEOAS est un principe de conception bénéfique pour la communication de machine à machine?

"Ça dépend". HATEOAS fait partie de la contrainte d' interface uniforme de REST.

En appliquant le principe de généralité du génie logiciel à l'interface des composants, l'architecture globale du système est simplifiée et la visibilité des interactions est améliorée. Les implémentations sont dissociées des services qu'elles fournissent, ce qui encourage une évolutivité indépendante. Le compromis, cependant, est qu'une interface uniforme dégrade l'efficacité, car les informations sont transférées sous une forme standardisée plutôt que spécifique aux besoins d'une application. L'interface REST est conçue pour être efficace pour le transfert de données hypermédia à gros grain, optimisée pour le cas commun du Web, mais résultant en une interface qui n'est pas optimale pour d'autres formes d'interaction architecturale.

Alors réfléchissons un instant à ce que cela signifie. Lorsque je rencontre des problèmes avec mon routeur sans fil, je peux communiquer avec lui en utilisant le même navigateur que j'utilise pour envoyer des réponses à stackexchange. En particulier, peu importe le navigateur que j'utilise ou si mon navigateur est à quelques mises à jour derrière (ou devant) ce que le routeur attend. Peu importe que l'organisation d'ingénierie qui a écrit le navigateur soit complètement indépendante de l'organisation qui a créé l'interface du routeur.

Ça marche juste .

Ce n'est bien sûr pas universel. Fielding, en 2008 , a écrit:

Cela ne signifie pas que je pense que chacun devrait concevoir ses propres systèmes selon le style architectural REST. REST est destiné aux applications réseau à longue durée de vie couvrant plusieurs organisations. Si vous ne voyez pas la nécessité des contraintes, ne les utilisez pas.

Les contraintes qui forment le style architectural REST ont été choisies pour les propriétés qu'elles induisent; si ces propriétés ne sont pas utiles à votre cas d'utilisation, vous devez absolument envisager de supprimer les contraintes correspondantes.

Là où la machine à machine devient difficile, c'est que vous avez perdu la capacité de l'être humain à faire correspondre de manière floue la sémantique fournie par les représentations. Les clients peuvent se débrouiller en ne connaissant que les types de médias, mais nous avons normalement un être humain qui regarde les indices sémantiques pour en tirer un sens.

schema.org fait partie d'un effort pour créer un vocabulaire lisible par machine; les agents de la machine utilisent le client pour trouver les indices sémantiques et appliquent sa propre compréhension du sens pour choisir les actions correctes à entreprendre.

Mais c'est du travail; vous devez investir dans le développement de représentations de vos ressources conviviales pour les machines, et vous assurer que ces représentations restent compatibles en amont et en aval, afin que les clients puissent être développés indépendamment.

Lorsqu'une seule organisation contrôle à la fois le client et le serveur, les avantages de cette indépendance sont beaucoup plus faibles, auquel cas la contrainte peut ne pas être un choix architectural approprié.

Non, le «REST complet» n'est pas terrible.

Comme en témoigne le manque de personnes qui implémentent HATEOS dans leurs API et les arguments sans fin sur lesquels le verbe HTTP à utiliser pour un appel particulier.

Mais vous devez reconnaître pourquoi REST est si populaire. Avant son adoption, il existait divers protocoles compliqués et fous tels que ebXML et SOAP impliquant des accusés de réception, des délais d'attente, des identifiants de conversation et des états.

Obtenir ces choses et les faire fonctionner, puis les expliquer aux consommateurs de l'API était une tâche difficile. "Pourquoi ne fais-je pas simplement un GET avec l'ID que je veux dans la chaîne de requête et vous m'envoyez les données?" était une question évidente et courante.

Ensuite, le deuxième problème était XML, javascript ne le comprenait pas, les schémas étaient une douleur dans le cul et vous vous retrouveriez avec d'énormes fichiers txt constitués principalement <MyLongObjectName>. Les gens ont donc commencé à utiliser JSON à la place.

Maintenant, REST a un peu de culte autour d'elle, mais parce que les règles sont si vagues qu'elles ne vous empêchent pas de créer une API utilisable qui est assez simple pour que les consommateurs `` l'obtiennent '' et l'utilisent sans 6 mois d'embarquement processus.

Il est à noter que Roy n'était pas l'inventeur original de la plupart des principes de REST, il rassemble de nombreux principes qui sont connus pour fonctionner dans les systèmes précédents pour résoudre divers problèmes spécifiques. REST est simplement la conclusion naturelle de l'application de ces principes dans une architecture unique.

Avant même que Roy Fielding n'écrive sa thèse sur REST , le HTTP était déjà conçu autour des principes qui deviendront plus tard REST. Dans la conclusion de sa thèse , il a écrit:

Au début de nos efforts au sein de l'Internet Engineering Taskforce pour définir le protocole de transfert hypertexte existant (HTTP / 1.0) [19] et concevoir les extensions pour les nouvelles normes HTTP / 1.1 [42] et les identificateurs de ressources uniformes (URI) [21] ], J'ai reconnu la nécessité d'un modèle de fonctionnement du World Wide Web. Ce modèle idéalisé des interactions au sein d'une application Web globale, appelé style architectural REST (Representational State Transfer), est devenu le fondement de l'architecture Web moderne, fournissant les principes directeurs permettant d'identifier les failles de l'architecture préexistante et d'extensions. validé avant le déploiement .

REST et HATEOS conviennent parfaitement au problème pour lequel il a été conçu:

REST est un ensemble coordonné de contraintes architecturales qui tente de minimiser la latence et la communication réseau tout en maximisant l'indépendance et l'évolutivité des implémentations de composants . Ceci est réalisé en plaçant des contraintes sur la sémantique des connecteurs là où d'autres styles se sont concentrés sur la sémantique des composants. REST permet la mise en cache et la réutilisation des interactions, la substituabilité dynamique des composants et le traitement des actions par des intermédiaires , répondant ainsi aux besoins d'un système hypermédia distribué à l'échelle d'Internet.

Cependant, il convient de noter que le Web et REST ne conviennent pas nécessairement à tous les problèmes:

De même, les extensions proposées peuvent être comparées à REST pour voir si elles s'intègrent dans l'architecture; sinon, il est plus efficace de rediriger cette fonctionnalité vers un système fonctionnant en parallèle avec un style architectural plus applicable.

Donc, si votre question est "REST et HATEOAS sont-ils une bonne architecture pour les services Web?" alors, la réponse est simplement "oui, c'est une bonne architecture pour les services web". Le problème est vraiment de savoir si tous les problèmes que les gens ont essayé de résoudre en les adaptant aux contraintes Web auraient dû être des services Web en premier lieu.

Il existe de nombreuses API qui ne correspondent vraiment pas à REST. Les API qui n'ont pas besoin du type d'évolutivité que REST est conçu pour résoudre, ne sont pas consommées par plusieurs organisations qui peuvent évoluer indépendamment et n'ont pas besoin d'être durables; pour ces problèmes, les contraintes REST ne sont qu'une camisole de force.

Mais y a-t-il réellement une raison de penser que REST est une architecture souhaitable pour ce domaine? Plus précisément, existe-t-il des preuves que HATEOAS est un principe de conception bénéfique pour la communication de machine à machine?

La preuve est le succès du Web à résoudre les problèmes de nombreuses personnes. REST est une architecture hybride, qui combine les conceptions de nombreux styles architecturaux précédents. De nombreux domaines problématiques n'ont pas toutes les exigences du Web et n'ont pas besoin d'obéir à toutes les contraintes de REST pour fonctionner correctement. C'est pourquoi il existe de nombreuses architectures réussies qui fonctionnent bien en appliquant simplement certaines parties de REST mais pas les autres. HATEOAS et Uniform Interface, par exemple, sont des principes qui sont souvent ignorés par les API qui n'ont pas besoin de traverser les frontières organisationnelles et les systèmes qui ont une période de dépréciation relativement courte.

Dans la présentation de Fielding sur Adobe Experience Manager:

REST n'est PAS une architecture!

Le repos est un style architectural, qui est l'abstraction d'une architecture différente qui existe sur Internet.

REST est une accumulation de contraintes de conception pour induire des propriétés architecturales

REST est un mot à la mode, et tout le monde veut avoir une API RESTful. En réalité, lorsque les personnes confrontées à des contraintes REST, elles ont abandonné certaines de ces contraintes car il n'y avait aucun besoin ou aucun avantage à gagner pour qu'elles appliquent toutes les contraintes.

Comme vous l'avez mentionné, HATEOAS est utile lorsque le client est un navigateur Web. Lorsque le client est une application mobile, peut-être pas tant que ça. Ce serait une bonne pratique, mais il y a aussi des coûts associés à la conception d'une application comme celle-là, à tel point que, pour donner un exemple, l'équipe des applications mobiles et l'équipe back-end ont juste accepté de supprimer cette contrainte. Et ce genre de sens parce que les deux équipes ne sont pas si faiblement couplées car elles travaillent pour la même entreprise.

REPOS dans AEM

si vous voulez créer un service consommé par un autre serveur, alors xmlrpc est le bon choix. Si ce que vous voulez, c'est un service destiné à être utilisé par des clients légers ou des appareils à faible consommation .. ou des clients inconnus sur Internet, envisagez peut-être de vous reposer en utilisant json. Mais rappelez-vous, json est une notation inférieure pour spécifier des données générales, par rapport à xml.