Un service Web de type Netflix ou Twitter devrait-il utiliser REST ou SOAP?
J'ai implémenté deux services REST: Twitter et Netflix. Les deux fois, j'ai eu du mal à trouver l'utilisation et la logique impliquées dans la décision d'exposer ces services comme REST = au lieu de SOAP. J'espère que quelqu'un pourra me faire comprendre ce qui me manque et expliquer pourquoi REST a été utilisé comme implémentation de service pour des services comme ceux-ci.
L'implémentation d'un service REST prend infiniment plus de temps que l'implémentation d'un service SOAP. Des outils existent pour tous les langages/frameworks/plates-formes modernes pour lire dans un WSDL et produire des classes proxy et les clients. L'implémentation d'un service REST se fait à la main et - obtenez ceci - en lisant la documentation. De plus, tout en implémentant ces deux services, vous devez faire des "suppositions" sur ce qui va revenir à travers le tuyau car il n'y a pas de véritable schéma ou document de référence.
Pourquoi écrire un service REST qui retourne de toute façon XML? La seule différence est qu'avec REST vous ne connaissez pas les types que chaque élément/attribut représente - vous êtes par vous-même pour l'implémenter et espérons qu'un jour une chaîne ne se rencontrera pas dans un champ que vous pensiez toujours être un entier. SOAP définit la structure de données en utilisant le WSDL c'est donc une évidence.
J'ai entendu la plainte selon laquelle avec SOAP vous avez le "surcoût" de l'enveloppe SOAP. De nos jours, avons-nous vraiment besoin de nous inquiéter) environ une poignée d'octets?
J'ai entendu l'argument selon lequel avec REST vous pouvez simplement insérer l'URL dans le navigateur et voir les données. Bien sûr, si votre service REST utilise simplement ou aucune authentification. Le service Netflix, par exemple, utilise OAuth qui vous oblige à signer des choses et à les encoder avant même de pouvoir soumettre votre demande.
Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource? Si nous utilisions un outil pour implémenter le service, nous soucions-nous vraiment de l'URL réelle?
n 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 panneaux d'avertissement
Vous avez tout à fait raison, la création de clients RESTful prend plus de temps que les clients SOAP. Les boîtes à outils SOAP enlèvent beaucoup de code standard et mettent à disposition des objets proxy client) avec presque aucun effort. Avec un outil comme Visual Studio et une URL de serveur, je peux accéder à des objets distants de 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 masse 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 un peu stupide cependant. Si ils avaient utilisé SOAP nous pourrions avoir codé nous-mêmes ces classes proxy.
Savon aérien, ha. C'est la latence qui tue. Si les gens sont vraiment préoccupés par le nombre d'octets excédentaires qui traversent le câble, alors HTTP n'est peut-être pas le bon choix. Avez-vous vu combien d'octets sont utilisés par l'en-tête user-agent?
Oui, 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 fait constamment obstacle, la gestion des erreurs engloutit tellement d'informations, elle recherche constamment un putain de favicon.ico. Tire-moi juste.
URL lisible. Seuls les noms, pas de verbes. Oui, c'est facile tant que nous ne faisons que des opérations CRUD et que nous devons uniquement accéder à une hiérarchie d'objets d'une manière. Malheureusement, la plupart des applications ont besoin d'un peu plus de fonctionnalités que cela.
La catastrophe imminente
Il y a une cargaison métrique de développeurs développant actuellement des applications qui s'intègrent avec les services REST) qui sont en train de tirer le même ensemble de conclusions que vous. On leur a promis simplicité, flexibilité, évolutivité, évolutivité et le Saint Graal de la réutilisation fortuite Les caractéristiques du web lui-même, comment les choses peuvent-elles mal tourner.
Cependant, ils constatent que le contrôle de version est tout autant un problème, 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. La conception d'API autour de noms et de quatre verbes peut être très difficile, en particulier avec les fanatiques d'URL RESTful qui vous indiquent quand vous pouvez et ne pouvez pas utiliser des chaînes de requête.
Les développeurs vont commencer à se demander pourquoi gaspillons-nous nos efforts à prendre en charge les formats Json et Xml, pourquoi ne pas simplement concentrer nos efforts sur un seul et le faire bien?
Comment les choses se sont-elles passées si mal
Je vais vous dire ce qui a mal tourné. En tant que développeurs, nous laissons les services marketing profiter de notre principale faiblesse. Notre recherche éternelle de la balle d'argent nous a aveuglés sur la réalité de ce qui est REST. En surface REST semble si facile et simple. Nommez vos ressources avec Urls et utiliser GET, PUT, POST et DELETE. Enfer, nous les développeurs savons déjà comment faire cela, nous avons eu affaire à des bases de données pendant des années qui ont des tables et des colonnes et des instructions SQL qui ont SELECT , INSÉRER, METTRE À JOUR et SUPPRIMER. Cela aurait dû être un morceau de gâteau.
Il y a d'autres parties de REST que certaines personnes discutent, comme l'auto-description 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 complexité où le but recherché est la simplicité.
Cette version édulcorée de REST est devenue validée dans la culture des développeurs de plusieurs façons. Des cadres de serveurs ont été créés qui encourageaient l'identification des ressources et l'interface uniforme, mais ne faisaient rien pour supporter les autres contraintes. Les termes ont commencé à flotter autour de la différenciation des 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 bouleversés par le fait que leur précieux terme avait été volé dans l'obscurité et rendu public. Les gens jaloux qui essaient de rendre REST sonne plus difficile qu'il ne l'est.
REST, le terme, est définitivement devenu courant. Presque tous les grands sites Web dotés d'une API prennent en charge "REST". Twitter et Netflix sont deux très prestigieux. Ce qui est effrayant, c'est que je ne peux penser qu'à une seule API publique auto-descriptive et il y en a une poignée qui met vraiment en œuvre 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!
Vous avez été induit en erreur, j'ai peur
Si vous avez réussi jusqu'ici, la réponse courte à votre question est que les API (Netflix et Twitter) ne sont pas conformes à toutes les contraintes et donc vous n'obtiendrez pas les avantages qui REST apis sont censés apporter.
Les clients REST prennent plus de temps à construire que les clients SOAP mais ils ne sont pas liés à un service spécifique, vous devriez donc être en mesure de les réutiliser sur plusieurs services. Prenons l'exemple classique d'un site Web navigateur. À combien de services un navigateur Web peut-il accéder? Qu'en est-il d'un lecteur de flux? À présent, à combien de services différents le client Twitter moyen peut-il accéder? Oui, un seul.
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 supports spécifiques qui pourraient être servis par n'importe quel service. La question évidente est de savoir comment construire 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. Vous l'avez dit vous-même,
vous devez faire des "suppositions" sur ce qui reviendra à travers le tuyau car il n'y a pas de véritable schéma ou document de référence
Vous avez absolument raison pour des services comme Twitter. Cependant, la contrainte d'auto-description dans REST dit que l'en-tête du type de contenu HTTP doit décrire exactement le contenu qui est transmis sur le fil. La livraison d'application/json et d'application/xml ne vous dit rien sur le contenu.
Quand il s'agit de considérer les performances des systèmes basés sur REST, il est nécessaire de regarder la situation dans son ensemble. Parler d'octets d'enveloppe, c'est comme parler de déroulement de boucle lors de la comparaison d'un tri rapide à un tri par Shell . Il existe des scénarios où SOAP peut mieux fonctionner, et il y a des scénarios où REST peut mieux fonctionner. Le contexte est tout.
REST gagne une grande partie de ses avantages 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 pour la mise en cache. Pour que la mise en cache fonctionne bien, la quasi-totalité des contraintes doit être respectée.
Votre dernier point sur les URL lisibles est de loin le plus ironique. Si vous vous engagez vraiment dans la contrainte hypermédia, 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'une des choses les plus importantes lors du développement de systèmes REST. Les URL lisibles sont pratiques pour le développeur du serveur et les URL bien structurées facilitent la structure du serveur pour envoyer des requêtes, mais ce sont des détails d'implémentation qui ne devraient pas avoir d'impact sur les développeurs utilisant l'API.
L'API Twitter n'est même pas près 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 le non-respect d'une seule contrainte peut avoir un impact profond sur les avantages dérivés du service.
Ce n'est peut-être pas entièrement de leur faute
J'ai fait beaucoup de dumping sur les fournisseurs de services, mais il en faut deux pour danser RESTfully. Un service peut suivre religieusement toutes les contraintes et un client peut toujours facilement annuler tous les avantages.
Si un client code dur des URL pour accéder à certains types de ressources, cela empêche le serveur de modifier ces URL. Toute construction d'URL basée sur une connaissance implicite de la façon dont le service structure ses URL est une violation.
Faire des hypothèses sur le type de représentation qui sera renvoyé à partir d'un lien peut entraîner des problèmes. Faire des hypothèses sur le contenu de la représentation sur la base de connaissances qui ne sont pas explicitement énoncées dans les en-têtes HTTP va certainement créer un couplage qui causera de la douleur à l'avenir.
Auraient-ils dû utiliser SOAP?
Personnellement, je ne pense pas. REST bien fait permet à un système distribué d'évoluer sur le long terme. Si vous construisez des systèmes distribués qui ont des composants développés par différentes personnes et qui doivent durer plusieurs années, alors REST est une assez bonne option.
SOAP est une pile technologique orientée objet, appel de procédure distante. Il fonctionne en construisant une nouvelle abstraction au-dessus d'un protocole existant (HTTP).
REST est une approche orientée document, qui utilise simplement les fonctionnalités d'un protocole existant (HTTP). "REST" n'est qu'un mot à la mode - le concept est le suivant: utilisez simplement le Web tel qu'il était conçu pour fonctionner!
En réponse aux modifications apportées à la question:
"L'implémentation d'un service REST prend infiniment plus de temps que l'implémentation d'un service SOAP."
Hum, non, ça ne peut pas être infiniment plus long. Et dans les cas où ce que vous essayez de récupérer est déjà un document ou un fichier, c'est en fait beaucoup plus rapide. Par exemple, la spécification OGC pour WMS (Web Mapping Service) définit à la fois une version SOAP et REST du protocole, et il y a une raison pour laquelle presque personne n'implémente le SOAP version - c'est parce que si vous essayez d'obtenir une carte, il est beaucoup plus facile de simplement créer une URL et de récupérer des octets d'image à partir de cette URL que de prendre la peine de l'encapsuler dans un SOAP message. Mais oui, je conviens que si le but du service Web est de transférer un objet fortement typé dans un modèle d'objet de domaine, SOAP est mieux adapté à cette utilisation.
"Pourquoi écrire un service REST qui retourne quand même XML?"
Eh bien, oui, cela peut être idiot. Mais cela dépend de ce qu'est le XML. S'il y a un schéma clairement défini quelque part, alors il n'y a pas d'ambiguïté. Par exemple, vous pouvez considérer les URL WSDL comme une sorte de service Web RESTful pour récupérer des informations sur un service Web. Dans ce cas, l'ajout de la surcharge d'une autre demande SOAP serait inutile.
En général, REST l'emporte lorsque le contenu qui est transféré peut être considéré comme un fichier, comme une seule unité. SOAP l'emporte lorsque le contenu doit être traité comme un objet avec membres.
"J'ai entendu la plainte selon laquelle avec SOAP vous avez la" surcharge "de l'enveloppe SOAP. De nos jours, avons-nous vraiment besoin de nous inquiéter de une poignée d'octets? "
Oui. Pas en toutes circonstances, mais il existe des sites avec beaucoup de trafic où cela fait une différence. Est-ce une différence suffisante pour l'emporter sur les différences sémantiques d'utiliser SOAP au lieu de REST? J'en doute. Si vous utilisez un protocole de communication à distance d'objets et que le nombre d'octets fait une différence, SOAP n'est probablement pas l'outil pour vous de toute façon - peut-être devriez-vous utiliser CORBA ou DCOM à la place.
"J'ai entendu l'argument qu'avec REST vous pouvez simplement insérer l'URL dans le navigateur et voir les données."
Oui, et ceci est un argument important en faveur de REST s'il est logique d'afficher les données dans un navigateur. Par exemple, avec les données d'image, c'est un moyen facile de déboguer le service - il suffit de coller l'URL dans la barre d'adresse de votre navigateur et de voir à quoi ressemble l'image. Ou si les données renvoyées sont en XML et que vous disposez d'une feuille de style XML référencée qui s'affiche en HTML lisible dans le navigateur, vous bénéficiez d'un balisage sémantique et d'une visualisation facile dans un seul package. Mais vous avez raison, cet avantage s'évapore surtout lorsque vous travaillez avec des schémas d'authentification plus complexes. Si vous ne pouvez pas encoder toutes vos informations d'authentification dans chaque requête HTTP, alors je dirais que cela ne compte pas du tout comme REST.
"Pourquoi avons-nous besoin d'une URL" lisible "pour chaque ressource? Si nous utilisions un outil pour implémenter le service, nous soucions-nous vraiment de l'URL réelle?"
En fait ça dépend. Pourquoi avons-nous besoin d'URL lisibles pour toute ressource sur le Web? Vous pouvez lire l'essai de Tim Berners-Lee Cool URIs Don't Change pour la justification, mais en gros, tant que la ressource peut encore être utile à l'avenir, l'URI car cette ressource doit rester la même.
De toute évidence, pour les ressources transitoires (comme le lien "L'argent d'aujourd'hui" dans l'essai), il n'est pas nécessaire, car la nécessité de référencer la ressource disparaît si la ressource correspondante disparaît. Mais pour des ressources plus permanentes (comme des questions StackOverflow, par exemple, ou des films sur IMDB), vous voulez avoir une URL qui fonctionnera pour toujours. Lorsque vous concevez un service Web, vous devez décider si les ressources elles-mêmes pourraient survivre à votre service, et si c'est le cas, alors REST est probablement la bonne voie à suivre.
Pour mémoire, oui, j'ai développé des pages Web bien avant que NetFlix ou Twitter n'existent. Et non, je n'ai pas encore eu besoin ou l'opportunité d'implémenter un client sur les services NetFlix ou Twitter. Mais même si leurs services sont atrocement difficiles à travailler, cela ne signifie pas que la technologie sur laquelle ils ont implémenté leurs services est mauvaise - seulement que ces deux implémentations sont mauvaises.
Pour faire une histoire courte: REST et SOAP sont juste des outils. Ils ont chacun leurs forces et leurs faiblesses. Si le seul outil dont vous disposez est un marteau, chaque problème ressemble à un clou. Apprenez donc à connaître les deux outils et apprenez à les utiliser correctement, puis choisissez le bon outil pour chaque travail.
Une question honnête mérite une réponse honnête. Mais d'abord, pourquoi avez-vous utilisé le texte de cette question comme réponse à une autre question si vous ne pensiez pas qu'il était de nature rhétorique?
En tous cas:
" Des outils existent pour tous les langages/frameworks/plates-formes modernes pour lire dans un WSDL et produire des classes et des clients proxy. L'implémentation d'un service REST se fait à la main en lisant la documentation. "
Tout comme les fournisseurs de navigateurs ont lu et relu la spécification HTML 4.01 de haut en bas pour essayer de mettre en œuvre une expérience de navigation cohérente. Avez-vous réfléchi au fait que les navigateurs ont été inventés bien avant les services bancaires par Internet et le stackoverflow, et pourtant, vous pouvez utiliser un navigateur pour faire exactement ces choses. Cela est rendu possible pour la seule raison que tout le monde accepte d'utiliser HTML (et les formats associés comme CSS, JS, JPEG, etc.).
Les blogs ne sont en fait pas si nouveaux, et quelqu'un a créé AtomPub, qui permet à n'importe quel logiciel de blog d'accéder et de mettre à jour les articles d'un blog, tout comme n'importe quel navigateur Web peut accéder à n'importe quelle page Web. C'est assez soigné et fonctionne en raison des contraintes RESTful imposées par le protocole.
Mais pour Twitter et Netflix, il n'y a pas d'accord universel sur le fait que "tous les microblogs existants doivent utiliser l'application de type média/Tweet", principalement parce que le microblogging est si nouveau. Peut-être que dans quelques années, quelques services de microblogging s'installeront sur la même API pour que Twitter, Facebook, Identica et puissent interagir. Aucune de leurs API existantes n'est proche de RESTful, même si elles le prétendent, donc je ne m'attends pas à ce que cela se produise très bientôt.
" De plus, lors de l'implémentation de ces deux services, vous devez faire des" suppositions "quant à ce qui reviendra à travers le canal car il n'y a pas de véritable schéma ou document de référence. "
Vous avez frappé le clou sur la tête. REST est entièrement distribué et hypermédia, et cela résume à peu près tout. Un navigateur regarde ce qu'il obtient d'une demande et le montre à l'utilisateur. Une page HTML génère généralement beaucoup plus de requêtes GET, par exemple CSS, scripts et images. Une image est généralement rendue uniquement à l'écran, JavaScript est exécuté, etc. Chaque fois, le navigateur fait ce qu'il fait car il a trouvé le lien dans une balise
<img>Ou<style>Et le type de support de réponse étaitimage/jpegOutext/css.Si Twitter crée une API basée sur l'hypermédia, il retournera probablement toujours un
application/TweetChaque fois que vous suivez un lien vers un Tweet, mais le client ne doit jamais l'assumer et vérifier toujours ce qu'il obtient avant d'agir." Pourquoi écrire un service REST qui retourne quand même XML? "
Tout cela se résume aux types de médias. Comme HTML, si vous voyez un élément dont vous n'avez aucune idée de ce que signifie réellement, la spécification HTML vous demande de les ignorer et de traiter le "corps" de la balise s'il en a un. De même, la spécification atom vous demande d'ignorer les éléments inconnus et les balises étrangères (provenant de différents espaces de noms) et not traiter le corps (IIRC).
La conception de types de médias pour des domaines de problèmes génériques (comme dans le type de média HTML pour le domaine de problème rich text) est très difficile. Il est probablement beaucoup plus facile de créer des types de supports pour des domaines problématiques très étroits (comme un Tweet). Mais c'est toujours une bonne idée de concevoir pour l'extensibilité et de spécifier comment les clients (et les serveurs) sont censés réagir lorsqu'ils voient des éléments ou des éléments de données qui ne correspondent pas aux spécifications. JPEG, par exemple, a un type d'enregistrement spécifique à l'application (par exemple APP1) qui est utilisé pour contenir toutes sortes de métadonnées.
" J'ai entendu la plainte selon laquelle avec SOAP vous avez les" frais généraux "de l'enveloppe SOAP. De nos jours, avons-nous vraiment besoin de nous inquiéter sur une poignée d'octets? "
Non, non. REST ne consiste absolument pas à être efficace sur le fil, il s'agit en fait d'échanger l'efficacité du fil. L'efficacité de REST vient des possibilités de mise en cache activées par toutes les autres contraintes: dissertation de Fielding notes: - 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. Je ne 'pense pas que le surdébit du nombre d'octets d'enveloppe SOAP est une préoccupation valable.
" J'ai entendu l'argument qu'avec REST, vous pouvez simplement insérer l'URL dans le navigateur et voir les données. "
Oui, c'est aussi un argument invalide. Cela ne fonctionne pas de cette façon. Même si cela a fonctionné, la plupart des API narrow REST utilisent des types de médias dont les navigateurs n'ont aucune idée et cela ne fonctionnera toujours pas.
Mais il existe beaucoup plus de possibilités qu'un navigateur pour tester une API basée sur HTTP, comme les utilitaires de ligne de commande ou les extensions de navigateur qui vous permettent de contrôler presque tous les aspects d'une demande HTTP, d'inspecter les en-têtes de réponse et de découvrir des liens à suivre. Mais même ainsi, cela est loin d'être aussi simple que de générer des stubs WSDL et de créer un programme à trois lignes pour appeler la fonction de toute façon.
" Pourquoi avons-nous besoin d'une URL" lisible "pour chaque ressource? Si nous utilisions un outil pour implémenter le service, nous soucions-nous vraiment de l'URL réelle? "
Si vous regardez le fonctionnement du Web, je suis à peu près sûr que les humains sont dans l'ensemble heureux que l'URI d'une page wikipedia ressemble à ceci,
http://en.wikipedia.org/wiki/Stack_overflowAu lieu dehttp://en.wikipedia.org/wiki/?oldid=376349090. Mais ce n'est pas important pour REST. L'essentiel pour essayer de bien faire est de choisir de placer dans l'URI des données pertinentes qui ne sont pas susceptibles de changer. Vous pourriez penser que l'ID de la base de données ne changera jamais, mais que se passe-t-il lorsque deux ensembles de données doivent être fusionnés? Toutes vos clés primaires changent. Le titre de la page (Stack_overflow) ne changera pas.
Désolé pour la longue réponse, mais je crois que cette question est valide et n'a pas été abordée avant ici sur SO. Je suis sûr que Darrel Miller ajoutera sa réponse une fois de retour.
Modifier: mise en forme
Martin Fowler a un article sur le modèle de maturité Richardson qui fait un excellent travail expliquant la différence entre SOAP et REST.
WSDL et d'autres protocoles de niveau document sont redondants. Le protocole HTTP prend en charge un ensemble d'opérations beaucoup plus riche en plus de simplement servir des documents et soumettre des formulaires.
Les partisans de REST ne sont pas à l'aise avec cette redondance.