Pourquoi utiliserait-on REST au lieu de services basés sur SOAP? [fermé]

Question

J'ai assisté à une démo intéressante sur REST aujourd'hui, cependant, je ne pouvais pas penser à une seule raison (et aucune n'a été présentée) pour laquelle REST est de toute façon plus facile ou plus simple à utiliser et à implémenter qu'une pile de services basée sur SOAP.

Quelles sont certaines des raisons pour lesquelles quiconque dans le "monde réel"? utiliser REST au lieu des services basés sur SOAP?

Answer 1

Moins de temps système (aucune enveloppe SOAP pour encapsuler chaque appel)

Moins de duplication (HTTP représente déjà des opérations telles que DELETE, PUT, GET, etc. qui doivent sinon être représentées dans une enveloppe SOAP).

Plus normalisé - Les opérations HTTP sont bien comprises et fonctionnent de manière cohérente. Certaines implémentations SOAP peuvent être difficiles.

Plus lisible et testable (plus difficile à tester SOAP avec juste un navigateur).

Vous n'avez pas besoin d'utiliser XML (vous ne devez pas non plus utiliser SOAP, mais cela n'a aucun sens, car vous êtes déjà en train d'analyser l'enveloppe).

Les bibliothèques ont rendu SOAP (en quelque sorte) facile. Mais vous souscrivez beaucoup de redondance, comme je l’ai noté. oui, en théorie, SOAP peut passer par d’autres moyens de transport afin d’éviter de chevaucher une couche similaire, mais en réalité, presque tout le travail SOAP que vous ferez se fera par HTTP.

Answer 2

Les

services RESTful sont beaucoup plus simples à consommer que Services standard (standard) de SOAP . La raison en est que REST est basé sur des requêtes HTTP normales, ce qui permet de déduire une intention du type de requête (GET = retrive, POST = write, DELETE =, etc.) et est totalement sans état. D’autre part, vous pourriez faire valoir que cette solution est moins souple, car elle supprime le concept d’une enveloppe de message contenant un contexte de requête.

Selon mon expérience, SOAP a été préféré pour les services au sein de l'entreprise et REST pour les services exposés en tant qu'API publique.

Avec des outils tels que WCF dans le framework .NET, il est très simple d'implémenter un service en tant que REST ou SOAP.

Quelques lectures pertinentes:

• blog des services Web Amazon: REST vs SOAP
• Dare Obasanjo écrit souvent à propos de REST

Answer 3

Je suppose que, lorsque vous parlez de "services Web", vous voulez dire SOAP et l'ensemble de normes WS- *. (Sinon, je pourrais affirmer que les services REST sont des "services Web".)

L'argument canonique est que les services REST correspondent plus étroitement à la conception du Web, c'est-à-dire à la conception de HTTP et de l'infrastructure associée. Ainsi, l’utilisation d’un service REST sera davantage compatible avec les outils et techniques Web existants.

Bien sûr, une fois que vous avez exploré les détails, vous découvrez que les deux approches ont des points forts dans différents scénarios. Est-ce que ce sont ces détails qui vous intéressent?

Answer 4

Les frais généraux ne sont pas aussi importants qu'une bonne architecture.

REST n'est pas un protocole, c'est une architecture qui encourage une bonne conception évolutive. Il est souvent choisi car trop de liberté dans RPC peut facilement conduire à une mauvaise conception.

L'autre raison est le coût prévisible des protocoles RESTful sur HTTP car il peut exploiter les technologies existantes (principalement les serveurs proxy). Le coût initial du RPC est assez faible, mais il a tendance à augmenter considérablement avec l'intensification de la charge.

Answer 5

REST est indépendant de la mise en œuvre et beaucoup plus transparent, ce qui en fait un atout majeur pour les API publiques, en particulier pour les grands sites Web tels que Flickr, Amazon ou Digg qui utilisent leurs API comme outils de marketing et souhaitent réellement que les utilisateurs consomment leurs données. Ils ne veulent pas vouloir être à la main avec des milliers de développeurs novices qui essaient de déboguer la bibliothèque buggy SOAP du langage de script de leur choix.

Versus SOAP et WSDL, qui conviennent mieux aux applications internes, où vous avez des bibliothèques en accès libre et des personnes clés connues aux deux extrémités. (Et vous n'avez peut-être pas à vous soucier de choses comme l'équilibrage de charge à l'échelle Internet, la mise en cache HTTP, etc.) Ensuite, vous obtenez des API auto-documentées, des types préservés, etc. sans travail.

Answer 6

J'ai lu l'excellent mémoire de Roy Fielding. sur le sujet. Il présente un excellent argument et il était WAY en avance sur son époque quand il l'a écrit (2000).

Answer 7

le blog de Steve Vinoski et son Les derniers articles méritent d’être consultés. C'est un ancien gourou de CORBA, qui a probablement écrit le meilleur livre sur le sujet avec Michi Henning, "Programmation CORBA® avancée avec C ++" . Cependant, il a depuis vu l'erreur de ses méthodes client / serveur et ne jure que par REST.

Answer 8

REST permet à vos opérations non mutantes (qui utilisent généralement le verbe GET) d'être en cache . C'est-à-dire, mis en cache par le client et / ou mis en cache par les mandataires. Cela peut être une énorme victoire!

Answer 9

REST est essentiellement un moyen d'implémenter des services Web. C’est un moyen d’utiliser correctement HTTP pour interroger les services Web que vous essayez de toucher.

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

Answer 10

C'est super simple et mince. Vous pouvez le faire avec un navigateur via http verbe: GET. Je n'ai pas trouvé de navigateur capable de faire facilement une demande HTTP POST générique manuellement

Answer 11

Voici un point de données: Amazon propose ses API aux formats REST et SOAP et 85% de l'utilisation est REST.

REST est plus simple à mettre en œuvre, à comprendre et à améliorer les performances.