Un canari dans une mine de charbon.
J'attends une question comme celle-ci depuis près d'un an maintenant. Il était inévitable que ce jour vienne et je suis sûr que nous allons voir beaucoup plus de questions comme celle-ci dans les mois à venir.
Les signes avant-coureurs
Vous avez tout à fait raison, il faut plus de temps pour créer des clients RESTful que des clients SOAP. Les boîtes à outils SOAP enlèvent beaucoup de code standard et rendent les objets proxy client disponibles presque sans effort. Avec un outil comme Visual Studio et une URL de serveur, je peux accéder à des objets distants d'une complexité arbitraire, localement en moins de cinq minutes.
Les services qui renvoient application / xml et application / json sont tellement ennuyeux pour les développeurs clients. Que sommes-nous censés faire avec cette goutte de données?
Heureusement, de nombreux sites qui fournissent des services REST fournissent également un tas de bibliothèques clientes afin que nous puissions utiliser ces bibliothèques pour accéder à un tas d'objets fortement typés. Cela semble plutôt stupide. S'ils avaient utilisé SOAP, nous pourrions créer nous-mêmes ces classes proxy.
SOAP frais généraux, ha. C'est la latence qui tue. Si les gens sont vraiment préoccupés par le nombre d'octets en excès qui traversent le câble, alors peut-être que HTTP n'est pas le bon choix. Avez-vous vu combien d'octets sont utilisés par l'en-tête user-agent?
Ouais, avez-vous déjà essayé d'utiliser un navigateur Web comme outil de débogage pour autre chose que HTML et javascript. Croyez-moi, ça craint. Vous ne pouvez utiliser que deux des verbes, la mise en cache est constamment gênante, la gestion des erreurs avale tellement d'informations, elle recherche constamment un putain de favicon.ico. Tirez sur moi.
URL lisible. Seulement des noms, pas de verbes. Oui, c'est facile tant que nous ne faisons que des opérations CRUD et que nous n'avons besoin d'accéder à une hiérarchie d'objets que d'une seule manière. Malheureusement, la plupart des applications ont besoin d'un tout petit peu plus de fonctionnalités que cela.
La catastrophe imminente
Il existe une multitude de développeurs qui développent actuellement des applications qui s'intègrent aux services REST et qui sont en train d'arriver au même ensemble de conclusions que vous. On leur promettait simplicité, flexibilité, évolutivité, évolutivité et le Saint Graal d'une réutilisation fortuite. Les caractéristiques du Web lui-même, comment les choses peuvent-elles mal tourner.
Cependant, ils constatent que la gestion des versions est tout aussi problématique, mais le compilateur n'aide pas à détecter les problèmes. Le code client écrit à la main est difficile à maintenir à mesure que les structures de données évoluent et que les URL sont refactorisées. Concevoir des API autour de noms et de quatre verbes peut être très difficile, en particulier avec les fanatiques d'URL RESTful vous indiquant quand vous pouvez et ne pouvez pas utiliser des chaînes de requête.
Les développeurs vont commencer à se demander pourquoi nous gaspillons nos efforts sur la prise en charge des formats Json et Xml, pourquoi ne pas concentrer nos efforts sur un seul et bien le faire?
Comment les choses ont-elles si mal tourné
Je vais vous dire ce qui ne va pas. En tant que développeurs, nous laissons les services marketing profiter de notre principale faiblesse. Notre recherche éternelle de la solution miracle nous a aveuglés sur la réalité de ce qu'est vraiment REST. En surface, REST semble si simple et facile. Nommez vos ressources avec des URL et utilisez GET, PUT, POST et DELETE. Bon sang, nous les développeurs savons déjà comment faire cela, nous traitons depuis des années avec des bases de données qui ont des tables et des colonnes et des instructions SQL qui ont SELECT, INSERT, UPDATE et DELETE. Cela aurait dû être un morceau de gâteau.
Certaines personnes discutent d'autres parties de REST, telles que l'auto-descriptivité et la contrainte hypermédia, mais ces contraintes ne sont pas aussi simples que l'identification des ressources et l'interface uniforme. Le semble ajouter de la complexité là où le but recherché est la simplicité.
Cette version édulcorée de REST a été validée dans la culture des développeurs à bien des égards. Des frameworks de serveur ont été créés pour encourager l'identification des ressources et l'interface uniforme, mais n'ont rien fait pour supporter les autres contraintes. Les termes ont commencé à flotter pour différencier les approches (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).
Quelques personnes crient que si vous n'appliquez pas toutes les contraintes, ce n'est pas REST. Vous n'obtiendrez pas les avantages. Il n'y a pas de demi-REPOS. Mais ces voix ont été étiquetées comme des fanatiques religieux qui étaient contrariés que leur précieux terme ait été volé à l'obscurité et rendu courant. Des gens jaloux qui essaient de rendre REST plus difficile qu'il ne l'est.
REST, le terme, est définitivement devenu courant. Presque toutes les propriétés Web majeures dotées d'une API prennent en charge "REST". Twitter et Netflix sont deux sites très médiatisés. Ce qui est effrayant, c'est que je ne peux penser qu'à une seule API publique auto-descriptive et qu'il y en a une poignée qui implémentent vraiment la contrainte hypermédia. Bien sûr, certains sites comme StackOverflow et Gowalla prennent en charge les liens dans leurs réponses, mais il y a d'énormes trous béants dans leurs liens. L'API StackOverflow n'a pas de page racine. Imaginez le succès du site Web s'il n'y avait pas de page d'accueil pour le site Web!
Tu as été induit en erreur, j'ai peur
Si vous êtes arrivé jusqu'ici, la réponse courte à votre question est que les API (Netflix et Twitter) ne sont pas conformes à toutes les contraintes et que vous n'obtiendrez donc pas les avantages que les apis REST sont censés apporter.
Les clients REST prennent plus de temps à créer que les clients SOAP, mais ils ne sont pas liés à un service spécifique, vous devriez donc pouvoir les réutiliser dans tous les services. Prenons l'exemple classique d'un navigateur Web. À combien de services un navigateur Web peut-il accéder? Qu'en est-il d'un lecteur de flux? Maintenant, à combien de services différents le client Twitter moyen peut-il accéder? Oui, juste un.
Les clients REST ne sont pas censés être construits pour s'interfacer avec un seul service, ils sont censés être construits pour gérer des types de média spécifiques qui pourraient être servis par n'importe quel service. La question évidente est de savoir comment créer un client REST pour un service qui fournit application / json ou application / xml. Eh bien, vous ne pouvez pas. C'est parce que ces formats sont complètement inutiles pour un client REST. Tu l'as dit toi-même,
vous devez faire des "suppositions" sur ce qui reviendra dans le tube car il n'y a pas de véritable schéma ou document de référence
Vous avez tout à fait raison pour des services comme Twitter. Cependant, la contrainte auto-descriptive de REST indique que l'en-tête de type de contenu HTTP doit décrire exactement le contenu qui est transmis sur le câble. Fournir application / json et application / xml ne vous dit rien sur le contenu.
Lorsqu'il s'agit de considérer les performances des systèmes basés sur REST, il est nécessaire d'avoir une vue d'ensemble. Parler d'octets d'enveloppe, c'est comme parler de déroulement de boucle lorsque l'on compare un tri rapide à un tri shell. Il existe des scénarios où SOAP peut mieux fonctionner, et il existe des scénarios où REST peut être plus performant. Le contexte est tout.
REST tire une grande partie de son avantage en termes de performances en étant très flexible sur les types de supports qu'il prend en charge et en ayant une prise en charge sophistiquée de la mise en cache. Pour que la mise en cache fonctionne correctement, presque toutes les contraintes doivent être respectées.
Votre dernier point sur les URL lisibles est de loin le plus ironique. Si vous vous engagez vraiment sur la contrainte hypermédia, alors chaque URL pourrait être un GUID et le développeur client ne perdrait rien en lisibilité.
Le fait que les URI doivent être opaques pour le client est l'un des éléments les plus importants lors du développement de systèmes REST. Les URL lisibles sont pratiques pour le développeur de serveur et des URL bien structurées facilitent l'envoi des requêtes par la structure du serveur, mais ce sont des détails d'implémentation qui ne devraient pas avoir d'impact sur les développeurs qui utilisent l'API.
L'API Twitter n'est même pas proche d'être RESTful et c'est pourquoi vous ne voyez aucun avantage à l'utiliser sur SOAP. L'API Netflix est beaucoup plus proche, mais son utilisation de types de supports génériques démontre que ne pas adhérer à une seule contrainte peut avoir un impact profond sur les avantages dérivés du service.
Ce n'est peut-être pas de leur faute
J'ai fait beaucoup de dumping sur les fournisseurs de services, mais il en faut deux pour danser de manière REST. Un service peut suivre toutes les contraintes religieusement et un client peut toujours facilement annuler tous les avantages.
Si un client code en dur des URL pour accéder à certains types de ressources, cela empêche le serveur de modifier ces URL. Toute construction d'URL de type basée sur une connaissance implicite de la manière dont le service structure ses URL est une violation.
Faire des hypothèses sur le type de représentation renvoyé par un lien peut entraîner des problèmes. Faire des hypothèses sur le contenu de la représentation en se basant sur des connaissances qui ne sont pas explicitement énoncées dans les en-têtes HTTP va certainement créer un couplage qui causera des problèmes à l'avenir.
Auraient-ils dû utiliser SOAP?
Personnellement, je ne pense pas. REST done right permet à un système distribué d'évoluer sur le long terme. Si vous créez des systèmes distribués dont les composants sont développés par différentes personnes et doivent durer de nombreuses années, alors REST est une très bonne option.