Comparer et opposer les services web REST et SOAP ?

Question

Je constate actuellement que les deux utilisent le protocole Internet (HTTP) pour échanger des données entre le consommateur et le fournisseur.

La différence est :

1. SOAP est un protocole de message basé sur XML, tandis que REST est un style architectural.
2. SOAP utilise WSDL pour la communication entre le consommateur et le fournisseur, tandis que REST utilise simplement XML ou JSON pour envoyer et recevoir des données.
3. SOAP invoque les services en appelant la méthode RPC, REST appelle simplement les services via le chemin URL.
4. SOAP ne renvoie pas de résultat lisible par l'homme, alors que REST est lisible avec un simple XML ou JSON.
5. SOAP ne se contente pas de passer par HTTP, il utilise également d'autres protocoles tels que SMTP, FTP, etc.

C'est tout ce que je sais sur les différences entre eux. Quelqu'un pourrait-il me corriger et en ajouter d'autres ?

Answer 1

SOAP utilise WSDL pour la communication entre le consommateur et le fournisseur, alors que REST utilise simplement XML ou JSON pour envoyer et recevoir des données.

WSDL définit le contrat entre le client et le service et est statique par nature. Dans le cas de REST, le contrat est quelque peu compliqué et est défini par HTTP, URI, Media Formats et Application Specific Coordination Protocol. Il est très dynamique, contrairement à WSDL.

SOAP ne renvoie pas de résultat lisible par l'homme, alors que REST est lisible avec un simple XML ou JSON.

Ce n'est pas vrai. Un simple XML ou JSON n'est pas du tout RESTful. Aucun d'entre eux ne définit de contrôles (c'est-à-dire des liens et des relations de liens, des informations sur les méthodes, des informations sur l'encodage, etc.), ce qui est contraire à REST dans la mesure où les messages doivent être autonomes et coordonner l'interaction entre l'agent/client et le service.

Grâce aux liens et aux relations sémantiques, les clients devraient être en mesure de déterminer la prochaine étape d'interaction, de suivre ces liens et de poursuivre la communication avec le service.

Il n'est pas nécessaire que les messages soient lisibles par l'homme, il est possible d'utiliser un format cryptique et de construire des applications REST parfaitement valides. Il importe peu que le message soit lisible par l'homme ou non.

Ainsi, les formats simples XML(application/xml) ou JSON(application/json) ne sont pas suffisants pour construire des applications REST. Il est toujours raisonnable d'utiliser un sous-ensemble de ces types de médias génériques qui ont une forte signification sémantique et offrent suffisamment d'informations de contrôle (liens, etc.) pour coordonner les interactions entre le client et le serveur.

• Pour plus de détails concernant les informations sur le contrôle, je vous recommande vivement de lire ceci : http://www.amundsen.com/hypermedia/hfactor/
• Liens Internet : http://tools.ietf.org/html/rfc5988
• Relations de liens enregistrés : http://www.iana.org/assignments/link-relations/link-relations.xml

REST ne fonctionne que sur HTTP

Ce n'est pas vrai, HTTP est le plus largement utilisé et lorsque nous parlons de services web REST, nous supposons simplement HTTP. HTTP définit une interface avec ses méthodes (GET, POST, PUT, DELETE, PATCH, etc.) et divers en-têtes qui peuvent être utilisés de manière uniforme pour interagir avec les ressources. Cette uniformité peut également être obtenue avec d'autres protocoles.

P.S. Une explication très simple, mais très intéressante de REST : http://www.looah.com/source/view/2284

Answer 2

En termes de programmation pratique au jour le jour, la plus grande différence réside dans le fait qu'avec SOAP, vous travaillez avec des formats d'échange de données statiques et fortement définis, alors qu'avec REST et JSON, le formatage de l'échange de données est très lâche en comparaison. Par exemple, avec SOAP, vous pouvez valider que les données échangées correspondent à un schéma XSD. Le XSD sert donc de "contrat" sur la façon dont le client et le serveur doivent comprendre comment les données échangées doivent être structurées.

Les données JSON sont généralement pas transmis selon un format fortement défini (à moins que vous n'utilisiez un cadre de travail qui le supporte par ex. http://msdn.microsoft.com/en-us/library/jj870778.aspx ou la mise en œuvre de json-schema).

En fait, certains (beaucoup/la plupart) diraient que la sauce secrète "dynamique" de JSON va à l'encontre de la philosophie/culture consistant à la contraindre par des contrats de données ( Les services web RESTful JSON doivent-ils utiliser un contrat de données ? )

Les personnes habituées à travailler dans des langages dynamiques faiblement typés ont tendance à se sentir plus à l'aise avec la souplesse de JSON, tandis que les développeurs issus de langages fortement typés préfèrent XML.

http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide

Answer 3

SOAP apporte son propre protocole et se concentre sur l'exposition d'éléments de logique applicative (et non de données) en tant que services. SOAP expose des opérations. SOAP se concentre sur l'accès à des opérations nommées, chacune mettant en œuvre une certaine logique commerciale par le biais de différentes interfaces.

Bien que SOAP soit communément appelé "services web", il s'agit d'une erreur. SOAP a très peu, voire rien, à voir avec le Web. REST fournit de véritables "services Web" basés sur les URI et HTTP.

A titre d'illustration, voici quelques appels et leur maison appropriée avec un commentaire.

getUser(User);

Il s'agit d'une opération de repos car vous accédez à une ressource (données).

switchCategory(User, OldCategory, NewCategory)

REST autorise de nombreux formats de données différents, alors que SOAP n'autorise que le XML. Bien que cela puisse sembler ajouter de la complexité à REST parce que vous devez gérer plusieurs formats, mon expérience m'a montré que c'était plutôt bénéfique. JSON est généralement mieux adapté aux données et s'analyse beaucoup plus rapidement. REST permet une meilleure prise en charge des clients navigateurs grâce à la prise en charge de JSON.