BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Overcoming RESTlessness

Overcoming RESTlessness

Favoris

Points Clés

  • Au cours des deux dernières années, il y a eu un sentiment croissant anti-REST dans la communauté de développement logiciel. Toutefois, les technologies de remplacement sont souvent apparues dans un contexte particulier, ce qui présente des forces et des faiblesses par rapport à des cas d'utilisation spécifiques.
  • L'essor de REST était lui-même alimenté par une fausse dichotomie, SOAP jouant le rôle de croque-mitaine. Alors que SOAP a tenté de fournir une méthode de tunneling à travers les protocoles du web, l'approche REST les a adoptés.
  • Au lieu de chercher à remplacer REST, l'industrie du génie logiciel devrait chercher à évoluer en s'appuyant sur la maturité de l'écosystème REST tout en exploitant les atouts technologiques des nouveaux protocoles.

Les nouveaux protocoles API comme GraphQL, gRPC et Apache Kafka ont gagné en popularité en tant qu'alternatives aux API HTTP inspirées par REST. Cet article soutient que la force du paradigme REST ne peut être reflétée dans les comparaisons individuelles de protocoles. Au lieu de chercher à remplacer REST, l'industrie du génie logiciel devrait chercher à évoluer en s'appuyant sur la maturité de l'écosystème REST tout en exploitant les atouts technologiques des nouveaux protocoles.

Surmonter le RESTless

Les nouveaux protocoles API comme GraphQL, gRPC et Apache Kafka ont gagné en popularité en tant qu'alternatives aux API HTTP inspirées par REST. Cet article soutient que la force du paradigme REST ne peut être reflétée dans les comparaisons individuelles de protocoles. Au lieu de chercher à remplacer REST, l'industrie du génie logiciel devrait chercher à évoluer en s'appuyant sur la maturité de l'écosystème REST tout en exploitant les atouts technologiques des nouveaux protocoles.

Sur les protocoles, les paradigmes et les fausses dichotomies....

Le récent billet du blog de Tim Bray, "Post-REST", a suscité beaucoup d'attention dans notre industrie, à juste titre. Au fur et à mesure que l'utilisation des API Web a augmenté, le scepticisme s'est accru quant à savoir si REST¹ est la convention de communication idéale pour les API Web. En plus de son champ d'application initial de communication Web ouverte, REST est maintenant utilisé pour fournir des données d'applications Web, fournir des communications inter-microservices, faciliter l'administration et l'automatisation de l'infrastructure et même pour des modèles asynchrones comme la messagerie, la distribution d'événements et le streaming.

L'article de Tim décrit bien l'utilisation de REST, ses limites perçues, certains protocoles alternatifs émergents (GraphQL et gRPC) et spécule sur l'avenir de la communication des API Web. Bien que je sois d'accord avec l'article en général, je pense qu'il y a plus à dire sur ce sujet. A savoir, plutôt que de regarder simplement ce qui pourrait remplacer REST, j'aimerais que nous examinions comment les forces de REST peuvent être synthétisées avec les innovations de ces nouveaux protocoles afin de proposer des alternatives évolutives pour la communication dans les écosystèmes logiciels distribués.

Nouveaux protocoles, anciennes lignes de bataille, fausses dichotomies

Au cours des deux dernières années, il y a eu un sentiment croissant d'anti-REST dans la communauté du développement de logiciels. De nombreux articles ont été publiés pour se plaindre des limites de REST, puis présenter un protocole ou une approche alternative de communication.

Le motif "REST est mauvais à x, donc utilisez plutôt y" peut être vu dans les articles qui supportent GraphQL, gRPC, la communication asynchrone, et des options encore plus obscures. Les arguments vont dans ce sens :

  • GraphQL est meilleur que REST parce qu'il permet au consommateur de l'API de contrôler les données qu'il reçoit, et permet au fournisseur de l'API d'agréger les ressources côté serveur.
  • gRPC (plus les Protocol Buffers) est meilleur que REST parce qu'il est type-safe, a une performance optimisée grâce à la sérialisation binaire et est capable d'exploiter les capacités de HTTP/2
  • La communication asynchrone (AMQP, Kafka, etc.) est meilleure que la communication synchrone REST car elle réduit le blocage et l'utilisation de threads et augmente ainsi l'autonomie du service.

Chacune de ces approches s'inscrit dans un contexte particulier. GraphQL a été créé par Facebook dans le cadre de leur refonte de l'application mobile Facebook. C'est la méthode de communication sur le réseau utilisée conjointement avec les frameworks Relay et React Native JavaScript, essentiellement un moyen de servir des données ad hoc à l'application. Comme on pouvait s'y attendre, de nombreux partisans publics de GraphQL ont tendance à privilégier la centricité des données et JavaScript. gRPC et les Protocol Buffers sont issus de l'utilisation interne de Google et ont suivi une voie similaire à celle du projet d'orchestration de conteneurs Kubernetes pour le public. Comme prévu, une grande partie du plaidoyer en faveur de gRPC est axé sur la communication entre les applications basées sur les conteneurs. La communication asynchrone exclusive est souvent encouragée pour une utilisation dans le contexte de systèmes réactifs ou de l’event sourcing. Il est logique que ces approches qui ont été conçues pour chacun de ces contextes spécifiques présentent certains avantages par rapport à l'approche REST plus générique dans ces contextes.

Pour la défense de REST, il est tentant de prendre ces critiques au pied de la lettre et de trouver des contrepoints comme ceux-ci :

  • Pour le cas de GraphQL, rien dans le paradigme REST n'empêche le choix du consommateur ou l'agrégation des ressources (l'utilisation d'interfaces statiques sur des ressources uniques n’a été qu’une pratique courante) et de nombreuses informations suggèrent que limiter le choix du consommateur a ses propres avantages
  • Pour gRPC, il est peu probable que l'optimisation de du temps d’exécution soit le principal goulot d'étranglement dans la plupart des architectures distribuées, et l'exigence de bibliothèque intégrée de gRPC - sans parler de la structure énumérée de protobuf - peut entraîner des problèmes imprévus
  • Pour l'asynchrone, il est absolument nécessaire d'inclure des scénarios événementiels, mais ceux-ci s'ajoutent probablement aux modèles synchrones comme les requêtes et les commandes.

Cependant, à mon avis, ces contre-arguments ne disent pas tout.2 Le génie logiciel est une industrie agitée, et nous simplifions souvent nos problèmes à l'excès afin de justifier des solutions trop simplistes. Nous aimons étiqueter la "burning platform" pour inciter les gens à sauter vers une nouvelle sécurité. Le traitement en temps réel est bon parce que le traitement par lots est mauvais. Les microservices sont bons parce que les monolithes sont mauvais. L'utilisation de REST comme croque-mitaine  contexte par contexte comme les arguments ci-dessus crée une série de fausses dichotomies. Plutôt que d'examiner ce qui manque à REST dans chacun des scénarios ci-dessus, nous devrions peut-être examiner une question différente : comment REST est-il devenu l'approche de communication par défaut pour les sauts de composant à composant en réseau dans l’informatique distribuée? Revenons au début.

Les origines, l'ascension et l'ubiquité de REST

REST (Representational State Transfer) a été défini comme un chapitre de la thèse de doctorat de Roy Fielding en 2000, "Architectural Styles and the Design of Network-based Software Architectures".Le méta-objectif de cet article était de " définir un cadre pour comprendre l'architecture logicielle... pour guider la conception architecturale des logiciels d'application en réseau ". REST a été inclus comme exemple de style architectural qui codifie les principes de conception du World Wide Web, en mettant l'accent sur l'évolutivité, la scalabilité et la généralité des interfaces. Comparé aux contextes des nouvelles approches énumérées ci-dessus, l'espace du problème initial de REST était large.

Aussi large soit-elle, l'idée d'utiliser le Web pour le partage en réseau de données et de services au-delà du navigateur était une idée populaire. Les développeurs de logiciels se sont rapidement emparés du travail de Fielding et ont misen pratique.3 L'essor de REST était lui-même alimenté par une fausse dichotomie, SOAP jouant le rôle de croque-mitaine. Alors que SOAP a tenté de fournir une méthode de tunneling à travers les protocoles du web, l'approche REST les a adoptés. Cette notion de REST étant "du web, pas seulement sur le web", elle est devenue un choix plus intuitif pour les ingénieurs logiciels qui construisent déjà des solutions basées sur le web.

Au fur et à mesure que l'écosystème SOAP et WS-* se compliquait, la relative simplicité et la facilité d'utilisation de REST l'emportaient. Au fil du temps, JSON a remplacé XML comme format de données de facto pour les API Web pour des raisons similaires. L'utilisation du paradigme de l'informatique Web s'est étendue à de nouveaux scénarios - intégration d'applications d'entreprise, le provisioning dans le cloud, interrogation de l'entrepôt de données, IoT - et l'adoption des API REST a suivi.

Maintenant, si l'on devait examiner chaque scénario d'utilisation spécifique, il pourrait y avoir quelques faiblesses dans l'applicabilité de REST, ou une approche alternative de communication qui semblerait plus idéale. Mais cet examen ne tiendrait pas compte du pouvoir que confère l'universalité de REST. En raison de l'omniprésence de REST, les développeurs Web habitués aux appels AJAX pouvaient intuitivement comprendre comment utiliser les API d'AWS pour provisionner l'infrastructure cloud ; les développeurs de réseaux sociaux basés sur le Web pouvaient rapidement mettre en place la plomberie des applications mobiles ; les développeurs d'entreprise avaient un moyen bien connu de faire communiquer entre eux les microservices nouvellement décomposés. Le génie logiciel est un domaine où les obstacles à la livraison sont souvent plus humains que machines. Des approches bien comprises apportent de la valeur et ont souvent un impact plus important sur les délais de livraison que des solutions de niche optimisées sur le plan technologique.

Cette universalité a également créé de la robustesse dans l'écosystème REST. Swagger -- maintenant OpenAPI -- est né organiquement comme une spécification de métadonnées pour aider les développeurs à documenter, concevoir et consommer les API. OAuth fournit un cadre évolutif et transférable pour l'authentification et l'autorisation. 4 "La gestion des API" est apparue comme un ensemble de capacités -- limitation de débit, routage dynamique, mise en cache, etc. -- qui s'est avérée communément utile lors de la fourniture d'API REST. L'exhaustivité du paradigme REST et la maturité de son écosystème représentent la plus grande valeur de REST en tant qu'approche de communication en réseau dans un système logiciel. Selon toute vraisemblance, cette ubiquité vient plus du fait que REST est "comment le Web fonctionne" que d'un détail technique quelconque.

La communication dans le paradigme post-Web

L'impact du Web sur le génie logiciel ne peut être surestimé. Parallèlement à l'essor de REST, le monde du génie logiciel a également vu l'avènement de l'open source, de l'Agile, du DevOps, du Domain-Driven Design et de l'architecture microservice. Chacun de ces mouvements a été rendu possible par le Web et, collectivement, ils ont amplifié l'importance de l'élément humain dans la livraison de logiciels. En plus de la souplesse et de la rapidité offertes par l'informatique dans le cloud, un nouveau paradigme du génie logiciel a émergé, caractérisé par des applications et des services faiblement couplés fonctionnant en continu et en constante évolution. Alors que Tim Bray appelait son article "post-REST", peut-être que ce nouveau paradigme pourrait-il s'appeler "post-Web". Et comme les caractéristiques de ce paradigme s'alignent sur les principes originaux de REST de Fielding, il ne serait pas logique d'abandonner REST et de partir de zéro. D'autre part, il serait tout aussi naïf d'ignorer deux décennies d'innovations technologiques.

Comment la valeur de REST peut-elle évoluer dans ce nouveau paradigme ? De plus en plus d'organisations adoptent une approche "API First" du développement logiciel, c'est-à-dire mettre l’accent sur l'importance de concevoir les interfaces machine dans leurs applications et services dans la même mesure que les interfaces utilisateur et utiliser ces API pour découpler les efforts de développement des équipes responsables de différents domaines. OpenAPI joue souvent un rôle important dans cette méthodologie, en tant que spécification d'interface "agnostique" d'implémentation. Conformément au paradigme post-Web, cela profite aux différentes personnes impliquées dans la construction ou la modification du système logiciel. Il y a déjà un projet en cours - AsyncAPI de Fran Mendez - qui vise à apporter cette même valeur aux interactions événementielles. Dans le même ordre d'idées, Mike Amundsen et Leonard Richardson ont introduit la spécification ALPS pour saisir la sémantique des interactions d'applications en réseau. De tels efforts aident à relever les défis liés au temps de conception et à la mise en place de systèmes distribués.

Il est également possible d'étendre la valeur de REST dans le cloud native runtime. Le passage aux microservices a introduit des limites de réseau là où la communication inter-processus (IPC) se faisait auparavant. Ces limites physiques peuvent être des projections des limites d'un domaine d'activité par conception, afin d'obtenir les avantages pour les personnes dont il a été question ci-dessus. Cependant, il y a un compromis implicite du runtime avec une latence supplémentaire du réseau et la possibilité de défaillances partielles dans la chaîne d'appels de service.

Le modèle Service Mesh répond à ces problèmes pour les systèmes basés sur des conteneurs, avec un proxy de service "sidecar" qui gère toutes les communications basées sur le réseau entre les composants applicatifs. La topologie du maillage de service signifie que l'IPC a été réintroduit entre les conteneurs d'application et leurs sidecars associés. Néanmoins, les développeurs de conteneurs d'applications doivent toujours spécifier les protocoles réseau dans leur code, car les proxies de service ne modifient généralement pas les protocoles de transport des messages proxy.

Ces développeurs d'applications devraient-ils s'occuper de la gestion des protocoles ? Pourraient-ils plutôt traiter les demandes de service abstraites (requêtes, commandes, événements) et faire en sorte que le serveur mandataire du service s'occupe du mappage, du transcodage et de la transmission du protocole ? Ces questions doivent être explorées, et la compréhension universelle de la conception des API REST en fonction du temps pourrait constituer un point de départ pour l'abstraction. Ce ne sont là que deux domaines où l'ubiquité de REST peut être mise à profit pour aider à consolider le paradigme post-Web.

Un avenir moins sans REST

Les tendances hype de la technologie vantent souvent comment elles peuvent remplacer l'ancienne approche par une nouvelle. En réalité, l'évolution du génie logiciel se fait généralement par couches. Chaque nouvelle innovation pose les fondations d'un nouvel ensemble d'innovations à venir. De nouveaux protocoles API tels que GraphQL, gRPC et Kafka remplaceront l'utilisation de messages HTTP basés sur les ressources, codés en JSON et transmis en HTTP dans certains scénarios distribués. Toutefois, l'héritage de REST dans l'évolution des systèmes distribués devrait porter moins sur les détails de son implémentation que sur les caractéristiques qui ont conduit à son ubiquité : fournir un cadre pour la connectivité universelle, découpler les consommateurs de services des fournisseurs, mettre l'accent sur la convivialité et l'accessibilité. Ce sont ces caractéristiques qui peuvent faire de REST - défini à l'origine comme le style architectural du Web - le fondement du paradigme post-Web du génie logiciel.

Notes de bas de page

  1. Le but de cet article n'est pas de débattre de la définition de REST. Le terme "REST" sera utilisé à la fois pour faire référence à la définition originale de Fielding et aux API de type CRUD sur HTTP.
  2. Pour une analyse pratique du contexte de décision REST/gRPC/GraphQL, lisez ce billet de Phil Sturgeon.
  3. ...et très tôt, la volonté de distiller REST au CRUD par HTTP était déjà encouragée.Voir ici.
  4. Pour en revenir à la dichotomie avec SOAP, ce développement de normes organiques contraste avec l'explosion des normes W3C et OASIS qui sont apparues pendant le pic du boom des Web Services au début des années 2000.

Merci à Mike Amundsen, Erik Wilde, Irakli Nadareishvili, et Ronnie Mitra pour avoir localisé les ressources "histoire de REST" énumérées dans cet article.

A propos de l'auteur

Matt McLarty est un architecte logiciel expérimenté qui dirige l'équipe de l'Académie API pour CA Technologies, une société de Broadcom. Il travaille en étroite collaboration avec les organisations à la conception et à la mise en œuvre de solutions API et de microservices innovantes et de qualité professionnelle. Matt a beaucoup travaillé dans le domaine de l'intégration et du traitement des transactions en temps réel pour des éditeurs de logiciels et des clients. Matt a récemment été co-auteur des livres O'Reilly Microservice Architecture et Securing Microservice APIs.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT