Un service Web de type Netflix ou Twitter doit-il utiliser REST ou SOAP? [fermé]

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 en tant que REST au lieu de SOAP. J'espère que quelqu'un pourra m'indiquer ce qui me manque et expliquer pourquoi REST a été utilisé comme implémentation de service pour des services tels que ceux-ci.

1. 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 à lire dans un WSDL et à produire des classes et clients proxy. L'implémentation d'un service REST se fait à la main et - obtenez ceci - en lisant la documentation. De plus, lors de l'implémentation de ces deux services, vous devez faire des "suppositions" sur ce qui reviendra à travers le tube car il n'y a pas de véritable schéma ou document de référence.

2. Pourquoi écrire un service REST qui renvoie quand même du XML? La seule différence est qu'avec REST, vous ne connaissez pas les types que chaque élément / attribut représente - vous êtes seul pour l'implémenter et espérez qu'un jour une chaîne ne se retrouvera pas dans un champ que vous pensiez toujours être un int. SOAP définit la structure de données à l'aide du WSDL, c'est donc une évidence.

3. J'ai entendu la plainte selon laquelle avec SOAP vous avez la "surcharge" de l'enveloppe SOAP. À notre époque, devons-nous vraiment nous soucier d'une poignée d'octets?

4. 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 une authentification simple ou aucune authentification. Le service Netflix, par exemple, utilise OAuth qui vous oblige à signer des choses et à encoder des choses avant même de pouvoir soumettre votre demande.

5. 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?

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.

SOAP est un orienté objet , procédure distante appel empilement technologique. 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 comme il a été conçu pour fonctionner!

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

1. "L'implémentation d'un service REST prend infiniment plus de temps que l'implémentation d'un service SOAP."

   Euh, 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 la version SOAP - c'est parce que si vous essayez d'obtenir une carte, c'est 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 se soucier de l'encapsuler dans un message SOAP. Mais oui, je conviendrai 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 quand même XML?"

   Eh bien, oui, cela peut être idiot. 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 pour récupérer des informations sur un service Web. Dans ce cas, l'ajout de la surcharge d'une autre requête SOAP serait inutile.

   En général, REST gagne lorsque le contenu en cours de transfert peut être considéré comme un fichier, comme une seule unité . SOAP gagne lorsque le contenu doit être traité comme un objet avec des membres .

3. "J'ai entendu dire qu'avec SOAP, vous avez la" surcharge "de l'enveloppe SOAP. A notre époque, devons-nous vraiment nous soucier d'une poignée d'octets?"

   Oui. Pas dans toutes les circonstances, mais il existe des sites avec beaucoup de trafic où cela fait la différence. Est-ce une différence suffisante pour compenser les différences sémantiques de l'utilisation de SOAP au lieu de REST? J'en doute. Si vous utilisez un protocole d'objet à distance 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, vous pouvez simplement insérer l'URL dans le navigateur et voir les données."

   Oui, et c'est un gros argument en faveur de REST s'il est judicieux d'afficher les données dans un navigateur . Par exemple, avec les données d'image, c'est un moyen simple 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 se traduit 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 principalement 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 , je dirais que cela ne compte pas du tout comme REST.

5. "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 fondamentalement, tant que la ressource peut encore être utile à l'avenir, l'URI de cette ressource doit rester le même.

   De toute évidence, pour les ressources transitoires (comme le lien "L'argent d'aujourd'hui" dans l'essai), cela n'est pas nécessaire, car le besoin 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 tel est le cas, 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 ni d'opportunité d'implémenter un client sur les services NetFlix ou 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 une histoire courte: REST et SOAP ne sont que des outils . Ils ont chacun des forces et des faiblesses. Si le seul outil dont vous disposez est un marteau, alors chaque problème ressemble à un clou. Alors apprenez à connaître les deux outils, 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 que c'était de nature rhétorique?

En tous cas:

1. " Des outils existent pour tous les langages / frameworks / plates-formes modernes pour lire dans un WSDL et sortir les classes et clients proxy. La mise en œuvre 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 d'implémenter une expérience de navigation cohérente. Avez-vous réfléchi au fait que les navigateurs ont été inventés bien avant la banque en ligne et le stackoverflow, et pourtant, vous pouvez utiliser un navigateur pour faire exactement ces choses. Ceci est rendu possible pour la seule raison que tout le monde accepte d'utiliser HTML (et les formats associés tels que CSS, JS, JPEG, etc.).

   Bloguer n'est en fait pas si nouveau, et quelqu'un a mis au point AtomPub, qui permet à tout logiciel de blogage 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 à cause des contraintes RESTful imposées par le protocole.

   Mais pour Twitter et Netflix, il n'y a pas d'accord universel selon lequel «tous les microblogs existants utiliseront le type de média application / tweet», principalement parce que le microblogage 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 s'ils le prétendent, donc je ne m'attends pas à ce que cela se produise très bientôt.

   " De plus, lors de la mise en œuvre de ces deux services, 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 frappé dans le mille. REST est une question de distribution et d'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 n'est généralement rendue qu'à 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 média de réponse était image/jpegou text/css.

   Si Twitter crée une API basée sur l'hypermédia, elle retournera probablement toujours un application/tweetchaque fois que vous suivrez un lien vers un tweet, mais le client ne devrait jamais l'assumer et toujours vérifier ce qu'il obtient avant d'agir.

2. " Pourquoi écrire un service REST qui renvoie 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 le balisage étranger (provenant d'espaces de noms différents) et de ne pas traiter le corps (IIRC).

   La conception de types de média pour des domaines problématiques génériques (comme dans le type de média HTML pour le domaine problématique de texte enrichi ) est très difficile. Créer des types de médias pour des domaines problématiques très étroits est probablement beaucoup plus facile (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.

3. " J'ai entendu dire qu'avec SOAP, vous avez la" surcharge "de l'enveloppe SOAP. A notre époque, devons-nous vraiment nous soucier d'une poignée d'octets? "

   Non, nous ne le faisons pas. REST ne consiste absolument pas à être efficace sur le fil, il s'agit en fait de négocier l'efficacité du fil. L'efficacité de REST vient des possibilités de mise en cache permises par toutes les autres contraintes: Notes de la thèse de Fielding : Le compromis, cependant, est qu'une interface uniforme se dégrade l'efficacité, puisque les informations sont transférées sous une forme standardisée plutôt que sous une forme 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 grains, optimisant pour le cas courant 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 la surcharge du nombre d'octets de l'enveloppe SOAP soit une préoccupation valable.

4. " J'ai entendu l'argument selon lequel 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 fonctionnait, la plupart des API REST étroites utilisent des types de médias dont les navigateurs n'ont aucune idée et cela ne fonctionnera toujours pas.

   Mais il y a beaucoup plus de possibilités qu'un navigateur pour tester une API basée sur HTTP, comme des utilitaires de 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 ainsi, c'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 quand même.

5. " 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 comment fonctionne le Web, je suis à peu près sûr que les humains sont en général heureux que l'URI d'une page wikipedia ressemble à ceci, http://en.wikipedia.org/wiki/Stack_overflowau lieu de http://en.wikipedia.org/wiki/?oldid=376349090. Mais ce n'est pas vraiment important de REST. La chose importante à essayer pour bien faire est de choisir de placer les données pertinentes dans l'URI qui ne sont pas susceptibles de changer. Vous pensez peut-être 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 auparavant ici sur SO. Je suis sûr que Darrel Miller ajoutera sa réponse une fois de retour.

Modifier: formatage

Martin Fowler a publié un article sur le modèle de maturité de Richardson qui fait un excellent travail pour expliquer la différence entre SOAP et REST.

WSDL et les 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.