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

SOAP est un orienté objet, appel de procédure à distance pile technologique. Cela 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" est juste un mot à la mode - le concept est le suivant: il suffit D'utiliser le web comme il était conçu pour fonctionner!

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

1. "mise en Œuvre d'un Le service REST prend infiniment plus de temps que l'implémentation d'un service SOAP."

   Euh, non, il ne peut pas être infiniment plus. 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 construire une URL et de récupérer des octets d'image à partir de cette URL que 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é à cet usage.

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

   Eh bien, oui, ça peut être idiot. Mais cela dépend de ce QU'est le XML. S'il y a un schéma clairement défini pour cela 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 requête SOAP serait inutile.

   En général, REST gagne lorsque le contenu transféré peut être considéré comme un fichier , comme une seule unité . Soap gagne lorsque le contenu doit être traité comme un objet avec membres .

3. "j'ai entendu la plainte qu'avec du savon, vous avez le "frais généraux" de L'enveloppe de savon. De nos jours, Avons-nous vraiment besoin de s'inquiéter d'une poignée d'octets?"

   Oui. Pas dans toutes les circonstances, mais il y a des sites avec beaucoup de trafic où cela fait une différence. Est-ce assez de différence pour l'emporter sur les différences sémantiques de L'utilisation de SOAP au lieu de REST? J'en doute. Si vous effectuez un protocole d'accès à distance d'objet et le nombre d'octets fait une différence, SOAP n'est probablement pas l'outil pour vous de toute façon-peut-être que vous devriez utiliser CORBA ou DCOM à la place.

4. "j'ai entendu l'argument selon lequel avec REST vous pouvez simplement pop L'URL dans le navigateur et voir les données."

   Oui, et c'est un grand argument en faveur de REPOS si elle fait sens pour 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 voir à quoi ressemble l'image. Ou si les données renvoyées sont en XML et que vous avez une feuille de style XML référencée qui se transforme en HTML lisible dans le navigateur, vous bénéficiez du balisage sémantique et de la visualisation facile dans 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 encoder toutes vos informations d'authentification dans chaque requête HTTP , alors je dirais que ça ne compte pas du tout comme du repos.

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?"

   Eh bien, ç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 Les URI Cool ne changent pas pour la raison, mais fondamentalement, tant que la ressource peut encore être utile à l'avenir, L'URI pour cela ressource devrait rester la même.

   Évidemment, pour les ressources transitoires (comme le lien "l'Argent d'aujourd'hui" dans l'essai), il n'y a pas besoin de cela, 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 oui, alors le repos est probablement la bonne façon d'aller.

Pour mémoire, Oui, j'ai développé des pages web bien avant L'existence de NetFlix ou Twitter. Et Non, Je n'ai pas encore eu le besoin ou l'occasion d'implémenter un client sur les services de NetFlix ou de Twitter. Mais même si leurs services sont atroce difficile de travailler avec, cela ne signifie pas que la technologie qu'ils ont mis en œuvre leurs services sur le dessus est mauvaise-seulement que ces deux implémentations sont mauvais.

Pour faire court: REST et SOAP sont juste des outils . Ils ont chacun des forces et des faiblesses. Si le seul outil que vous avez est un marteau, alors chaque problème ressemble à un clou. Alors apprenez à 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 que c'était de nature rhétorique?

Quoi Qu'il en soit:

1. "des outils existent pour tous les langages/frameworks/plates-formes modernes à lire dans un WSDL et des classes proxy de sortie et des clients. 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 relisez 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 sur le 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 ces choses. Ceci est rendu possible en raison de la seule raison que tout le monde accepte d'utiliser HTML (et les formats connexes comme CSS, JS, JPEG, etc.).

   Blogging est en fait pas nouveau, et quelqu'un est venu avec AtomPub, qui permet à tout logiciel de blogging pour accéder et mettre à jour les messages dans un blog, un peu 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 que "tous les microblogs existants doivent utiliser le type de média application/tweet", principalement parce que le microblogging est si Nouveau. Peut-être que dans quelques années, quelques services de micro-blogging s'installent sur la même API pour que Twitter, Facebook, Identica et peut interopérer. 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 arrive très bientôt.

   "En outre, lors de la mise en œuvre de 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."

   Vous avez frappé le clou sur la tête. REST est tout au sujet distribué et hypermédia, et cela résume à peu près. 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 uniquement rendue à 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 était image/jpeg ou text/css.

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

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

   Tout cela se résume aux types de médias. Comme HTML, si vous voyez un élément que 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 si elle en a une. De même, la spécification atom vous indique d'ignorer les éléments inconnus et le balisage étranger (à partir de différents espaces de noms) et Pas traiter le corps (IIRC).

   La conception de types de média pour les domaines à problèmes génériques (comme dans le type de média HTML pour le domaine à problèmes rich text) est très difficile. Faire des types de Médias pour des domaines à problèmes 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 specs. 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 la plainte qu'avec du savon, vous avez le "frais généraux" de L'enveloppe de savon. De nos jours, Avons-nous vraiment besoin de s'inquiéter d'une poignée d'octets?"

   NON, nous ne le faisons pas. le reste n'est absolument pas d'être efficace sur le fil, c'est en fait échanger l'efficacité du fil. L'efficacité de REST vient du 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é, puisque l'information est transférée 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 grains, optimisant pour le cas commun du Web, mais résultant en une interface qui n'est pas optimale pour d'autres formes de l'interaction architecturale. Je ne pense pas que la surcharge du nombre D'octets de L'enveloppe SOAP soit une préoccupation valide.

4. "j'ai entendu l'argument selon lequel avec REST vous pouvez simplement pop L'URL dans le navigateur et voir les données."

   Oui, c'est aussi un argument invalide. Il ne fonctionne pas de cette façon. Même si cela a fonctionné, la plupart des API RESTétroites utilisent des types de médias que les navigateurs n'ont aucune idée et cela ne fonctionnera toujours pas.

   Mais il y a un 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 requête 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 facile que de générer des stubs WSDL et de créer un programme à 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 soucions-nous vraiment de L'URL réelle?"

   Si vous regardez comment fonctionne le web, Je suis 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_overflow au lieu de http://en.wikipedia.org/wiki/?oldid=376349090. Mais il n'est pas important de se reposer. La chose importante à essayer de bien faire est de choisir de placer des données pertinentes dans L'URI qui ne sont pas susceptibles de changer. Vous pourriez penser que l'ID de base de données ne changera jamais, mais que se passe-t-il lorsque deux ensembles de données doivent être fusionné? 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 qu'il sera de retour aussi.

Modifier: formatage

Martin Fowler a un post sur le modèle de maturité 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 servir des documents et de soumettre des formulaires.

Les partisans du repos sont mal à l'aise avec cette redondance.