Un service web de type Netflix ou Twitter doit-il utiliser REST ou SOAP ?

Question

J'ai mis en place 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 en tant que REST au lieu de SOAP. J'espère que quelqu'un pourra m'éclairer sur ce qui m'échappe et m'expliquer pourquoi REST a été utilisé comme mise en œuvre de services tels que ceux-ci.

1. La mise en œuvre d'un service REST est infiniment plus longue que celle d'un service SOAP. Il existe des outils pour tous les langages, cadres et plates-formes modernes permettant de lire un WSDL et de générer des classes et des clients proxy. L'implémentation d'un service REST se fait à la main et - tenez-vous bien - en lisant de la documentation. De plus, lors de la mise en œuvre de ces deux services, vous devez deviner ce qui sera renvoyé par le tuyau, car il n'existe pas de véritable schéma ou document de référence.

2. Pourquoi écrire un service REST qui renvoie du XML de toute façon ? La seule différence est qu'avec REST, vous ne connaissez pas les types que chaque élément/attribut représente - vous êtes tout seul pour l'implémenter et espoir qu'un jour une chaîne de caractères n'apparaisse pas dans un champ que vous pensiez être toujours un int. SOAP définit la structure des données à l'aide du WSDL, c'est donc une évidence.

3. J'ai entendu dire qu'avec SOAP, il y a les "frais généraux" de l'enveloppe SOAP. À notre époque, avons-nous vraiment besoin de nous préoccuper d'une poignée d'octets ?

4. J'ai entendu l'argument selon lequel avec REST, il suffit d'insérer l'URL dans le navigateur pour voir les données. Bien sûr, si votre service REST utilise une authentification simple ou inexistante. Le service Netflix, par exemple, utilise OAuth, qui vous oblige à signer et à coder des éléments avant même de pouvoir soumettre votre requête.

5. Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource ? Si nous utilisions un outil pour mettre en œuvre le service, nous soucierions-nous vraiment de l'URL réelle ?

Answer 1

Un canari dans une mine de charbon.

Cela fait près d'un an que j'attends une question comme celle-ci. Il était inévitable que ce jour arrive et je suis sûr que nous allons voir beaucoup d'autres questions de ce genre dans les mois à venir.

Les signes d'alerte

Vous avez tout à fait raison, il faut plus de temps pour construire des clients RESTful que des clients SOAP. Les boîtes à outils SOAP éliminent une grande partie du code standard et mettent à disposition des objets proxy clients presque sans effort. Avec un outil comme Visual Studio et une URL de serveur, je peux accéder localement à des objets distants d'une complexité arbitraire en moins de cinq minutes.

Les services qui renvoient des applications/xml et des applications/json sont si ennuyeux pour les développeurs de clients. Que sommes-nous censés faire avec cette masse de données ?

Heureusement, de nombreux sites qui proposent des services REST fournissent également un ensemble de bibliothèques clientes afin que nous puissions utiliser ces bibliothèques pour accéder à un ensemble d'objets fortement typés. C'est quand même un peu bête. S'ils avaient utilisé SOAP, nous aurions pu coder ces classes proxy nous-mêmes.

La surcharge SOAP, ha. C'est la latence qui tue. Si les gens sont vraiment préoccupés par le nombre d'octets excédentaires qui transitent sur le fil, 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 ?

Ouais, avez-vous déjà essayé d'utiliser un navigateur web comme outil de débogage pour autre chose que du HTML et du javascript. Croyez-moi, ça craint. Vous ne pouvez utiliser que deux des verbes, le cache est constamment dans le chemin, la gestion des erreurs avale tellement d'informations, il est constamment à la recherche d'un putain de favicon.ico. Tuez-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 peu plus de fonctionnalités que cela.

La catastrophe imminente

Un grand nombre de développeurs développent actuellement des applications qui s'intègrent aux services REST et sont en train d'arriver aux mêmes conclusions que vous. On leur a promis la simplicité, la flexibilité, l'extensibilité, l'é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 versionnage est tout aussi problématique, mais que le compilateur ne permet pas de détecter les problèmes. Le code client écrit à la main est difficile à maintenir, car les structures de données évoluent et les URL sont remaniées. Concevoir des API autour de simples noms et de quatre verbes peut s'avérer très difficile, surtout avec les zélateurs des URL RESTful qui vous disent quand vous pouvez ou non utiliser des chaînes de requête.

Les développeurs vont commencer à se demander pourquoi nous gaspillons nos efforts à supporter les deux formats Json et Xml, pourquoi ne pas concentrer nos efforts sur un seul et le faire bien ?

Comment les choses ont-elles pu si mal tourner ?

Je vais vous dire ce qui a mal tourné. En tant que développeurs, nous avons laissé les services marketing profiter de notre principale faiblesse. Notre éternelle recherche de la solution miracle nous a aveuglés sur la réalité de ce qu'est REST. En apparence, REST semble si facile et si simple. Nommez vos ressources avec des Urls et utilisez GET, PUT, POST et DELETE. Bon sang, nous, les développeurs, savons déjà comment faire, nous nous occupons depuis des années de bases de données avec des tables, des colonnes et des instructions SQL avec SELECT, INSERT, UPDATE et DELETE. Cela aurait dû être un jeu d'enfant.

Certaines personnes discutent d'autres parties de REST, comme l'autodescription et la contrainte d'hypermédia, mais ces contraintes ne sont pas aussi simples que l'identification des ressources et l'interface uniforme. Elles semblent ajouter de la complexité là où le but recherché est la simplicité.

Cette version édulcorée de REST s'est imposée dans la culture des développeurs de plusieurs manières. Des cadres de serveur ont été créés qui encourageaient l'identification des ressources et l'interface uniforme, mais ne faisaient rien pour supporter les autres contraintes. Des termes ont commencé à circuler pour différencier les approches (HI-REST vs LO-REST, Corporate REST vs Academic REST, REST vs RESTful).

Quelques personnes ont crié que si vous n'appliquez pas toutes les contraintes, ce n'est pas REST. Vous n'en tirerez pas les avantages. Il n'y a pas de demi-REST. Mais ces voix ont été étiquetées comme étant des fanatiques religieux qui étaient contrariés que leur précieux terme ait été volé de l'obscurité et rendu courant. Des personnes jalouses qui essaient de faire passer REST pour plus difficile qu'il ne l'est.

REST, le terme, est définitivement devenu courant. Presque toutes les grandes entreprises du web qui ont une API supportent "REST". Twitter et Netflix en sont deux exemples très connus. Ce qui est effrayant, c'est que je ne connais qu'une seule API publique qui soit autodescriptive et qu'il n'y en a qu'une poignée qui applique vraiment la contrainte hypermédia. Bien sûr, certains sites comme StackOverflow et Gowalla prennent en charge les liens dans leurs réponses, mais leurs liens présentent d'énormes lacunes. L'API de 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'en ai peur.

Si vous êtes arrivé jusqu'ici, la réponse courte à votre question est que ces API (Netflix et Twitter) ne se conforment pas à toutes les contraintes et que vous ne bénéficierez donc pas des avantages que les API REST sont censées apporter.

Les clients REST sont plus longs à construire que les clients SOAP, mais ils ne sont pas liés à un service spécifique, vous devriez donc pouvoir les réutiliser entre 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 ? À 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 médias spécifiques qui pourraient être servis par n'importe quel service. La question évidente est la suivante : comment construire un client REST pour un service qui fournit des applications/json ou des applications/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 qui reviendra dans le tuyau, car car il n'y a pas de véritable schéma ou document

Vous avez tout à fait raison pour des services comme Twitter. Cependant, la contrainte d'autodescription de REST stipule que l'en-tête de type de contenu HTTP doit décrire exactement le contenu qui est transmis sur le fil. Transmettre 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 en comparant un tri rapide à un tri shell. Il y a des scénarios où SOAP peut être plus performant, et il y a des scénarios où REST peut être plus performant. Le contexte est essentiel.

REST tire une grande partie de son avantage en termes de performances en étant très souple quant aux types de médias qu'il prend en charge et en disposant d'un support sophistiqué pour la mise en cache. Pour que la mise en cache fonctionne bien, il faut toutefois respecter presque toutes les contraintes.

Votre dernier point concernant les urls lisibles est de loin le plus ironique. Si vous vous engagez réellement à respecter la contrainte de l'hypermédia, alors chaque URL pourrait être un GUID et le développeur du 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. Des URL lisibles sont pratiques pour le développeur du serveur et des URL bien structurées facilitent la répartition des demandes par le cadre du serveur, mais il s'agit de détails de mise en œuvre qui ne devraient avoir aucun impact sur les développeurs qui utilisent l'API.

L'API Twitter est loin d'être RESTful et c'est pourquoi vous ne voyez aucun avantage à l'utiliser par rapport à SOAP. L'API de Netflix est beaucoup plus proche, mais son utilisation de types de médias génériques démontre que le non-respect d'une seule contrainte peut avoir un impact profond sur les avantages tirés du service.

Ce n'est peut-être pas entièrement de leur faute

Je me suis beaucoup déchargé sur les fournisseurs de services, mais il faut être 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 les urls pour accéder à certains types de ressources, il empêche le serveur de modifier ces urls. Toute construction d'URL basée sur une connaissance implicite de la manière dont le service structure ses urls constitue une violation.

Faire des hypothèses sur le type de représentation qui sera renvoyé par un lien peut entraîner des problèmes. Faire des suppositions sur le contenu de la représentation en se basant sur des connaissances qui ne sont pas explicitement indiquées dans les en-têtes HTTP va certainement créer un couplage qui sera source de difficultés à l'avenir.

Auraient-ils dû utiliser SOAP ?

Personnellement, je ne le pense pas. REST bien fait permet à un système distribué d'évoluer sur le long terme. Si vous construisez des systèmes distribués dont les composants sont développés par différentes personnes et qui doivent durer de nombreuses années, alors REST est une très bonne option.

Answer 2

SOAP est un orienté objet , appel de procédure à distance pile technologique. Il fonctionne en construisant une nouvelle abstraction au-dessus d'un protocole existant (HTTP).

REST est un orienté vers les documents qui utilise simplement les caractéristiques d'un protocole existant (HTTP). "REST" n'est qu'un mot à la mode - le concept est le suivant : Il suffit d'utiliser le web comme il l'a été conçu au travail !

En réponse aux modifications apportées à la question :

1. "La mise en œuvre d'un service REST est infiniment plus longue que celle d'un service SOAP."

   Um, non, ça ne peut pas être infiniment plus longtemps. 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 ne met en œuvre la version SOAP - c'est parce que si vous essayez d'obtenir une carte, il est beaucoup plus facile de construire une URL et de récupérer des octets d'image à partir de cette URL que de s'embêter à l'encapsuler dans un message SOAP. Mais oui, je suis d'accord 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.

2. "Pourquoi écrire un service REST qui renvoie du XML de toute façon ?"

   Eh bien, oui, cela peut être stupide. Mais cela dépend de ce qu'est le XML. S'il existe un schéma clairement défini quelque part, il n'y a pas d'ambiguïté. Par exemple, vous pouvez considérer les URL WSDL comme une sorte de service web RESTful permettant de récupérer des informations sur un service web. Dans ce cas, il serait inutile d'ajouter une autre requête SOAP.

   En général, REST l'emporte lorsque le contenu transféré peut être considéré comme un élément d'information. comme une seule unité . SOAP l'emporte quand le contenu doit être traité comme une avec des membres .

3. "J'ai entendu la plainte selon laquelle avec SOAP, vous avez les "frais généraux" de l'enveloppe SOAP. À notre époque, avons-nous vraiment besoin de nous préoccuper d'une poignée d'octets ?"

   Oui. Pas dans toutes les circonstances, mais il y a des sites à fort trafic où cela fait une différence. La différence est-elle suffisante pour contrebalancer les inconvénients de l'utilisation de l'Internet ? différences sémantiques d'utiliser SOAP au lieu de REST ? J'en doute. Si vous faites un protocole de remoting d'objet et que le nombre d'octets fait une différence, SOAP n'est probablement pas l'outil qu'il vous faut de toute façon -- peut-être devriez-vous utiliser CORBA ou DCOM à la place.

4. "J'ai entendu l'argument selon lequel avec REST, il suffit d'insérer l'URL dans le navigateur pour voir les données."

   Oui, et c'est un argument de poids en faveur de REST. s'il est judicieux de visualiser les données dans un navigateur . Par exemple, avec des 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 au format XML, et que vous disposez d'une feuille de style XML référencée qui donne un rendu HTML lisible dans le navigateur, vous bénéficiez des avantages du balisage sémantique et de la visualisation facile, le tout en un seul paquet. Mais vous avez raison, cet avantage s'évapore principalement lorsque vous travaillez avec des schémas d'authentification plus complexes. Si vous ne pouvez pas coder toutes vos informations d'authentification dans chaque requête HTTP alors je dirais qu'il ne s'agit pas du tout de REST.

5. "Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource ? Si nous utilisions un outil pour mettre en œuvre le service, nous soucions-nous vraiment de l'URL réelle ?"

   Eh bien, cela dépend. Pourquoi avons-nous besoin d'URL lisibles pour toute ressource sur le web ? Vous pouvez lire l'essai de Tim Berners-Lee Les URI cool ne changent pas pour le raisonnement, mais en gros, tant que la ressource peut encore être utile à l'avenir, l'URI de cette ressource doit rester le même.

   Évidemment, pour les ressources éphémères (comme le lien "Today's Money" dans l'essai), ce n'est pas nécessaire, puisque le besoin de référencer la ressource disparaît si la ressource correspondante disparaît. Mais pour les ressources plus permanentes (comme les questions StackOverflow, par exemple, ou les films sur IMDB), vous voulez avoir une URL qui fonctionnera toujours. Lorsque vous concevez un service Web, vous devez décider si les ressources elles-mêmes peuvent survivre à votre service et, dans l'affirmative, REST est probablement la bonne solution.

Pour mémoire, oui, je développe des pages web bien avant que NetFlix ou Twitter n'existent. Et non, je n'ai pas encore eu besoin ou l'occasion de mettre en œuvre un client pour les services de NetFlix ou de Twitter. Mais même si leurs services sont atrocement difficiles à utiliser, 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 court : REST et SOAP sont juste des outils . Ils ont tous des forces et des 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 à les utiliser correctement, puis choisissez le bon outil pour chaque tâche.

Answer 3

Une question honnête mérite une réponse honnête. Mais d'abord, pourquoi avez-vous utilisé le texte de cette question comme une réponse à une autre question si vous ne pensiez pas que c'était de nature rhétorique ?

De toute façon :

1. " Il existe des outils pour tous les langages, cadres et plates-formes modernes permettant de lire un WSDL et de générer 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 en long et en large 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 sur Internet et stackoverflow, et pourtant, vous pouvez utiliser un navigateur pour faire exactement ces choses. Cela est possible pour la seule raison que tout le monde est d'accord pour utiliser le HTML (et les formats connexes comme CSS, JS, JPEG, etc.).

   Les blogs ne sont pas si nouveaux que cela, et quelqu'un a créé AtomPub, qui permet à n'importe quel logiciel de blog d'accéder aux articles d'un blog et de les mettre à jour, comme n'importe quel navigateur Web peut accéder à n'importe quelle page Web. C'est assez génial, et cela fonctionne grâce aux contraintes RESTful imposées par le protocole.

   Mais pour Twitter et Netflix, il n'existe pas d'accord universel selon lequel "tous les microblogs existants doivent utiliser le type de média application/tweet", principalement parce que le microblogging est si récent. Peut-être que dans quelques années, quelques services de microblogging se mettront d'accord sur la même API afin que Twitter, Facebook, Identica et autres puissent interagir. Aucune de leurs API existantes n'est proche de RESTful, même s'ils le prétendent, donc je ne m'attends pas à ce que cela arrive de sitôt.

   " En outre, lors de la mise en œuvre de ces deux services, vous devez faire des "suppositions" quant à ce qui va revenir par le tuyau, car il n'existe pas de véritable schéma ou document de référence. "

   Vous avez mis le doigt sur le problème. REST, c'est du distribué et de l'hypermédia, et ça résume bien la situation. Un navigateur regarde ce qu'il obtient d'une requête et le montre à l'utilisateur. Une page HTML génère généralement beaucoup de requêtes GET, par exemple des CSS, des scripts et des images. Une image est généralement rendue à l'écran, JavaScript est exécuté, et ainsi de suite. À chaque fois, le navigateur fait ce qu'il fait parce qu'il a trouvé le lien dans une demande GET. <img> ou <style> et le type de média de la réponse était image/jpeg ou text/css .

   Si Twitter crée une API basée sur l'hypermédia, elle renverra probablement toujours un message de type application/tweet chaque fois que vous suivez un lien vers un tweet, mais le client ne doit jamais le supposer, et toujours vérifier ce qu'il reçoit avant d'agir.

2. " Pourquoi écrire un service REST qui renvoie du XML de toute façon ? "

   Tout cela se résume aux types de médias. Comme pour le HTML, si vous voyez un élément dont vous n'avez aucune idée de la signification, la spécification HTML vous demande de l'ignorer et de traiter le "corps" de la balise s'il en a un. De même, la spécification atomique vous demande d'ignorer les éléments inconnus et les balises étrangères (provenant de différents espaces de noms) et de traiter le "corps" de la balise si elle en a un. pas traiter le corps (IIRC).

   Concevoir des types de médias pour des domaines de problèmes génériques (comme dans le cas de la HTML type de support pour le texte riche domaine problématique) est très difficile. Il est probablement beaucoup plus facile de créer des types de médias pour des domaines 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 données qui ne correspondent pas à la spécification. JPEG, par exemple, possède un type d'enregistrement spécifique à l'application (par exemple APP1) qui est utilisé pour contenir toutes sortes de métadonnées.

3. " J'ai entendu dire qu'avec SOAP, il y a les "frais généraux" de l'enveloppe SOAP. À notre époque, avons-nous vraiment besoin de nous préoccuper d'une poignée d'octets ? "

   Non, nous ne le faisons pas. REST n'a absolument rien à voir avec l'efficacité sur le fil, il s'agit en fait d'échanger l'efficacité sur le fil. L'efficacité de REST provient des possibilités de mise en cache permises par toutes les autres contraintes : La dissertation de Fielding notes : La contrepartie, toutefois, est qu'une interface uniforme nuit à l'efficacité, puisque 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 à grande échelle, 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 surcoût du nombre d'octets de l'enveloppe SOAP soit une préoccupation valable.

4. " J'ai entendu l'argument selon lequel avec REST, il suffit d'insérer l'URL dans le navigateur pour voir les données. "

   Oui, c'est aussi un argument invalide. Ca ne fonctionne pas comme ça. Même si ça marchait, la plupart étroit Les API REST utilisent des types de médias dont les navigateurs n'ont aucune idée et cela ne fonctionne toujours pas.

   Mais il existe bien d'autres possibilités qu'un navigateur pour tester une API basée sur HTTP, comme des utilitaires en ligne de commande ou des extensions de navigateur qui vous permettent de contrôler presque tous les aspects d'une requête HTTP, d'inspecter les en-têtes de réponse et de découvrir des liens à suivre. Mais même dans ce cas, c'est loin d'être aussi facile que de générer des stubs WSDL et de faire un programme en trois lignes pour appeler la fonction de toute façon.

5. " Pourquoi avons-nous besoin d'une URL "lisible" pour chaque ressource ? Si nous utilisions un outil pour mettre en œuvre le service, nous soucierions-nous vraiment de l'URL réelle ? "

   Si vous regardez comment le web fonctionne, je suis presque sûr que les humains sont en général contents que l'URI d'une page wikipedia ressemble à ceci, http://en.wikipedia.org/wiki/Stack_overflow au lieu de http://en.wikipedia.org/wiki/?oldid=376349090 . Mais ce n'est pas vraiment important pour REST. Ce qu'il faut essayer de faire, c'est de choisir de placer dans l'URI des données pertinentes qui ne sont pas susceptibles de changer. Vous pouvez 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 cette longue réponse, mais je pense que cette question est valable et qu'elle n'a pas été abordée auparavant sur SO. Je suis sûr que Darrel Miller ajoutera sa réponse dès qu'il sera de retour lui aussi.

Edit : formatage

Answer 4

Martin Fowler a un post sur le modèle de maturité de Richardson qui explique très bien la différence entre SOAP et REST.

Answer 5

WSDL et les autres protocoles au niveau des documents sont redondants. Le protocole HTTP prend en charge un ensemble d'opérations beaucoup plus riche que la simple diffusion de documents et la soumission de formulaires.

Les partisans de REST ne sont pas à l'aise avec cette redondance.