1223 votes

SOAP vs REST (différences)

J'ai lu des articles sur les différences entre SOAP et REST en tant que protocole de communication de service Web, mais je pense que le plus grand avantage pour REST over SOAP est:

  1. REST est plus dynamique, pas besoin de créer et de mettre à jour UDDI.

  2. REST n'est pas limité au format XML. Les services Web REST peuvent envoyer du texte brut, JSON et XML.

Mais le SOAP est plus standardisé (Ex, sécurité).

Alors, ai-je raison sur ces points?

1733voto

Pedro Werneck Points 3744

Malheureusement, il y a beaucoup de désinformation et de fausses idées autour de RESTE. Non seulement votre question et la réponse par @cmd reflètent ceux-ci, mais la plupart des questions et des réponses sur le sujet sur un Débordement de Pile.

SOAP et REST ne peuvent pas être comparées directement, puisque le premier est un protocole (ou au moins essaie de l'être) et le deuxième est un style architectural. C'est probablement l'une des sources de confusion autour de lui, car les gens ont tendance à appeler RESTE tout de l'API HTTP qui n'est pas de SAVON.

En poussant les choses un peu et essayer d'établir une comparaison, la principale différence entre le SAVON et le RESTE est le degré de couplage entre le client et le serveur des mises en œuvre. Un client SOAP fonctionne comme une coutume application de bureau, étroitement couplé au serveur. Il y a un rigide contrat entre le client et le serveur, et tout est prévu pour briser si l'une des parties change quoi que ce soit. Vous avez besoin d'une mise à jour permanente suite à tout changement.

Un client REST est plus comme un navigateur. C'est un client générique qui sait comment utiliser un protocole et des méthodes normalisées, et une application doit s'adapter à l'intérieur. Vous ne violez pas les normes de protocole par la création de méthodes supplémentaires, vous avez un effet de levier sur les méthodes standard et de créer des actions avec eux sur le type de support. Si c'est bien fait, il y a moins de couplage, et les changements peuvent être traités avec plus de douceur. Un client est censé entrer dans un service REST avec zéro connaissance de l'API, sauf pour le point d'entrée et le type de média. Dans la fabrication du SAVON, le client doit déjà des connaissances sur tout ce qu'il va utiliser, ou s'il ne commence même pas l'interaction. En outre, un client REST peut être étendu par le code sur demande fourni par le serveur lui-même, l'exemple classique étant le code javascript utilisé pour conduire l'interaction avec un autre service sur le côté client.

Je pense que ce sont des points cruciaux pour comprendre ce qui RESTE est et comment elle diffère de SAVON:

  • RESTE est indépendant du protocole. Il n'est pas couplé à HTTP. Un peu comme, vous pouvez suivre un lien ftp sur un site web, une application REST pouvez utiliser n'importe quel protocole pour lequel il existe une standardisé schéma d'URI.

  • Le REPOS n'est pas la cartographie CRUD pour les méthodes HTTP. Lire cette réponse pour une explication détaillée sur ce point.

  • Le REPOS est aussi standardisés que les pièces que vous utilisez. La sécurité et l'authentification HTTP est normalisé, c'est ce que vous utilisez lorsque vous faites RESTE sur HTTP.

  • Le REPOS n'est pas en RESTE, sans HATEOAS. Cela signifie qu'un client ne connaît que le point d'entrée de l'URI et les ressources sont supposées liaisons de retour le client doit suivre. Les amateurs de documentation générateurs de donner URI modèles pour tout ce que vous pouvez faire dans une API REST de manquer le point complètement. Ils ne sont pas seulement de documenter quelque chose qui est censé être la norme, mais quand vous le faites, vous manœuvrez le client à un moment donné de l'évolution de l'API, et des modifications dans l'API doivent être documentées et appliquées, ou qu'il va se casser.

  • Le REPOS est le style architectural de l'internet lui-même. Lorsque vous entrez dans un Débordement de Pile, vous savez ce qu'est un Utilisateur, une Question et une Réponse, vous connaissez les types de médias, et le site vous donne les liens. Une API REST a à faire de même. Si nous avons conçu le web, la façon de penser des gens RESTE doit être fait, au lieu d'avoir une page d'accueil avec des liens vers les Questions et les Réponses, nous aurions une statique de la documentation expliquant que pour afficher une question, vous devez prendre l'URI stackoverflow.com/questions/<id>, remplacez l'id de la Question.l'id et le coller sur votre navigateur. C'est absurde, mais c'est ce que beaucoup de gens pensent que le REPOS est.

Ce dernier point ne peut pas être assez souligné. Si vos clients sont la construction d'Uri à partir de modèles en matière de documentation et de ne pas obtenir des liens dans la ressource représentations, ce n'est pas le REPOS. Roy Fielding, l'auteur de REPOS, il est clair sur ce blog: les Api REST doit être hypertexte-driven.

Dans cet esprit, vous vous rendrez compte que tandis que le RESTE pourrait ne pas être limité au format XML, afin de le faire correctement avec n'importe quel autre format, vous aurez à concevoir et à standardiser un format pour vos liens. Les hyperliens sont un standard dans le fichier XML, mais pas en JSON. Il y a des projets de normes pour le JSON, comme HAL.

Enfin, le RESTE, ce n'est pas pour tout le monde, et la preuve de cela est de savoir comment la plupart des gens à résoudre leurs problèmes très bien avec les Api HTTP ils appellent de REPOS et de ne jamais s'aventurer au-delà. Le REPOS est difficile parfois, surtout au début, mais ça paye plus de temps et plus facile d'évolution sur le côté serveur et client de la résilience aux changements. Si vous avez besoin quelque chose de rapide et facile, ne vous inquiétez pas à propos de se RESTE à droite. Ce n'est probablement pas ce que vous cherchez. Si vous avez besoin de quelque chose qui va rester en ligne pendant des années, voire des décennies, alors RESTE est pour vous.

283voto

cmd Points 2517

REST vs SOAP est pas la bonne question à poser.

REST, contrairement aux SOAP est pas un protocole.

REST est un style d'architecture et de conception de réseau basée sur les architectures logicielles.

REST et SOAP sont pas mutuellement exclusives. Une bonne architecture peut utiliser HTTP ou SOAP comme le protocole de communication sous-jacent

REST concepts sont mentionnés comme des ressources. Une représentation d'une ressource doit être apatrides. Il est représenté par le biais de certains type de média. Quelques exemples de types de médias comprennent XML, JSON, et RDF. Les ressources sont manipulés par les composants. Les composants de la demande et de manipuler des ressources par l'intermédiaire d'une norme uniforme de l'interface. Dans le cas de HTTP, cette interface se compose de la norme HTTP ops par exemple, GET, PUT, POST, DELETE.

@Abdulaziz la question ne éclairer le fait qu' REST et HTTP sont souvent utilisés en tandem. Cela est principalement dû à la simplicité de HTTP et de son très naturel cartographie RESTful principes.

Fondamental RESTE Principes

Communication Client-Serveur

Architectures Client-serveur ont une très nette séparation des préoccupations. Toutes les applications créées dans le repos de style doit également être client-serveur dans princple.

Apatrides

Chaque client demande au serveur exige que son état soit pleinement représentée. Le serveur doit être en mesure de bien comprendre la demande du client sans l'aide de tout le contexte du serveur, ou serveur de l'état de la session. Il s'ensuit que tout état doit être maintenu sur le client. Nous allons discuter de apatrides représentation plus en détail plus tard.

Pouvant être mis en cache

Cache contraintes peuvent être utilisés, permettant ainsi à des données de réponse à être marqué comme pouvant être mis en cache ou non cachable. Toutes les données marquées comme pouvant être mis en cache peut être réutilisé comme réponse à la même demande.

Interface Uniforme

Tous les composants doivent interagir par le biais d'une seule interface uniforme. Parce que tous les composants d'interaction se produit par le biais de cette interface, interaction avec les différents services est très simple. L'interface est la même! Cela signifie également que la mise en œuvre des modifications peuvent être apportées dans l'isolement. Ces changements n'affectent pas l'élément fondamental de l'interaction, car l'interface uniforme est toujours inchangé. Un désavantage est que vous êtes coincé avec l'interface. Si une optimisation peut être fourni à un service spécifique en changeant l'interface, vous êtes hors de la chance que RESTE interdit. Sur le côté positif, cependant, le RESTE est optimisé pour le web, d'où l'incroyable popularité de REPOS sur HTTP!

Les concepts ci-dessus représentent les caractéristiques de REPOS et de se différencier du RESTE de l'architecture à partir d'autres architectures comme les services web. Il est utile de noter que le RESTE du service est un service web, mais un service web n'est pas nécessairement un service REST.

Voir ce blog post sur le RESTE principes de Design pour plus de détails sur le REPOS et la énoncées ci-dessus balles.

EDIT: mise à jour du contenu sur la base des commentaires

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X