SOAP vs REST (différences)

1242

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 les plus grands avantages de REST sur SOAP sont:

  1. REST est plus dynamique, pas besoin de créer et de mettre à jour UDDI (Universal Description, Discovery, and Integration).

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

Mais SOAP est plus standardisé (ex: sécurité).

Alors, ai-je raison sur ces points?

Abdulaziz
la source
181
Il y a une analogie avec les lettres que j'aimais beaucoup à propos de SOAP vs REST, avec SOAP vous utilisez une enveloppe, avec REST, c'est une carte postale , donc évidemment SOAP a un surcoût supplémentaire: plus de bande passante (plus de papier), travail supplémentaire pour les deux parties ( emballage et déballage). Mais cela ne signifie pas que REST n'est pas aussi sécurisé que SOAP car vous pouvez utiliser HTTPS (pensez-y comme remplaçant le facteur par quelqu'un qui ne parle que des langues étrangères)
watashiSHUN
2
spf13.com/post/soap-vs-rest
Migrate2Lazarus voir mon profil
4
Selon le modèle de maturité Richardson qui décompose les principaux éléments d'une approche REST en trois étapes, SOAP est de niveau 0 REST.
Sampada

Réponses:

1757

Malheureusement, il y a beaucoup de désinformation et d'idées fausses autour de REST. Non seulement votre question et la réponse de @cmd reflètent celles-ci, mais la plupart des questions et réponses liées au sujet sur Stack Overflow.

SOAP et REST ne peuvent pas être comparés directement, car le premier est un protocole (ou du moins essaie de l'être) et le second est un style architectural. C'est probablement l'une des sources de confusion à ce sujet, car les gens ont tendance à appeler REST toute API HTTP qui n'est pas SOAP.

En poussant un peu les choses et en essayant d'établir une comparaison, la principale différence entre SOAP et REST est le degré de couplage entre les implémentations client et serveur. Un client SOAP fonctionne comme une application de bureau personnalisée, étroitement couplée au serveur. Il y a un contrat rigide entre le client et le serveur, et tout devrait se casser si l'un ou l'autre côté change quelque chose. Vous avez besoin de mises à jour constantes après tout changement, mais il est plus facile de vérifier si le contrat est respecté.

Un client REST ressemble plus à un navigateur. C'est un client générique qui sait utiliser un protocole et des méthodes standardisées, et une application doit s'y adapter. Vous ne violez pas les normes de protocole en créant des méthodes supplémentaires, vous tirez parti des méthodes standard et créez les actions avec elles sur votre type de support. Si cela est fait correctement, il y a moins de couplage et les modifications peuvent être traitées plus gracieusement. Un client est censé entrer dans un service REST sans aucune connaissance de l'API, à l'exception du point d'entrée et du type de support. Dans SOAP, le client a besoin de connaissances préalables sur tout ce qu'il utilisera, ou il ne commencera même pas l'interaction. De plus, un client REST peut être étendu par du code à la demande fourni par le serveur lui-même,

Je pense que ce sont les points cruciaux pour comprendre en quoi consiste REST et en quoi il diffère de SOAP:

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

  • REST n'est pas un mappage de CRUD aux méthodes HTTP. Lisez cette réponse pour une explication détaillée à ce sujet.

  • REST est aussi standardisé que les pièces que vous utilisez. La sécurité et l'authentification dans HTTP sont standardisées, c'est donc ce que vous utilisez lorsque vous effectuez REST sur HTTP.

  • REST n'est pas REST sans hypermédia et HATEOAS . Cela signifie qu'un client ne connaît que l'URI du point d'entrée et que les ressources sont censées renvoyer les liens que le client doit suivre. Ces générateurs de documentation sophistiqués qui donnent des modèles d'URI pour tout ce que vous pouvez faire dans une API REST manquent complètement le point. Ils documentent non seulement quelque chose qui est censé suivre la norme, mais lorsque vous faites cela, vous associez le client à un moment particulier de l'évolution de l'API, et tout changement sur l'API doit être documenté et appliqué, ou il se cassera.

  • REST est le style architectural du Web lui-même. Lorsque vous entrez Stack Overflow, vous savez ce qu'est un utilisateur, une question et une réponse, vous connaissez les types de supports et le site Web vous fournit les liens vers ceux-ci. Une API REST doit faire de même. Si nous concevions le Web de la façon dont les gens pensent que REST devrait être fait, au lieu d'avoir une page d'accueil avec des liens vers des questions et réponses, nous aurions une documentation statique expliquant que pour afficher une question, vous devez prendre l'URI stackoverflow.com/questions/<id>, remplacez id par le Question.id et collez-le sur votre navigateur. C'est absurde, mais c'est ce que beaucoup de gens pensent que REST est.

Ce dernier point ne peut pas être suffisamment souligné. Si vos clients créent des URI à partir de modèles dans la documentation et n'obtiennent pas de liens dans les représentations de ressources, ce n'est pas REST. Roy Fielding, l'auteur de REST, l'a clairement indiqué sur ce billet de blog: les API REST doivent être basées sur l'hypertexte .

En tenant compte de ce qui précède, vous vous rendrez compte que bien que REST ne soit pas limité au XML, pour le faire correctement avec tout autre format, vous devrez concevoir et normaliser un certain format pour vos liens. Les hyperliens sont standard en XML, mais pas en JSON. Il existe des projets de normes pour JSON, comme HAL .

Enfin, REST n'est pas pour tout le monde, et la preuve en est que la plupart des gens résolvent très bien leurs problèmes avec les API HTTP qu'ils ont appelées à tort REST et ne s'aventurent jamais au-delà. REST est parfois difficile à faire, surtout au début, mais il paie au fil du temps avec une évolution plus facile côté serveur et la résilience du client aux changements. Si vous avez besoin que quelque chose soit fait rapidement et facilement, ne vous souciez pas de bien vous reposer. Ce n'est probablement pas ce que vous recherchez. Si vous avez besoin de quelque chose qui devra rester en ligne pendant des années, voire des décennies, REST est fait pour vous.

Pedro Werneck
la source
8
Soit on va bien. Le problème est de savoir comment les utilisateurs obtiennent les URL, et non comment ils les utilisent. Ils devraient obtenir l'URL de recherche à partir d'un lien dans un autre document, pas dans la documentation. La documentation peut expliquer comment utiliser la ressource de recherche.
Pedro Werneck
2
@CristiPotlog Je n'ai jamais dit que SOAP dépend d'un protocole particulier, je souligne simplement que REST ne l'est pas. Le deuxième lien que vous avez envoyé indique que REST nécessite HTTP, ce qui est faux.
Pedro Werneck
4
Répétons cela encore une fois: HATEOAS est une contrainte si vous voulez appeler votre API Restful!
Orestis
3
@SachinKainth Il y a une réponse à cela ici . Vous pouvez mapper les opérations CRUD aux méthodes HTTP, mais ce n'est pas REST, car ce n'est pas la sémantique voulue de ces méthodes, comme indiqué dans les RFC.
Pedro Werneck
3
Les 4 dernières lignes sont des pierres précieuses et doivent être parfaitement comprises par la personne en développement. Faire du repos pur prend du temps mais donne des récompenses à plus long terme. Donc mieux pour les projets de taille moyenne ou grande. Pas bon pour le prototypage et les petits projets.
Rajan Chauhan
288

RESTvs SOAPn'est pas la bonne question à poser.

REST, contrairement à ce SOAPn'est pas un protocole.

RESTest un style architectural et une conception pour les architectures logicielles basées sur le réseau.

RESTles concepts sont appelés ressources. Une représentation d'une ressource doit être apatride. Il est représenté via un type de média. Comprennent quelques exemples de types de médias XML, JSONet RDF. Les ressources sont manipulées par les composants. Les composants demandent et manipulent des ressources via une interface uniforme standard. Dans le cas de HTTP, cette interface se compose d'opérations HTTP standard par exemple GET, PUT, POST, DELETE.

@ La question d'Abdulaziz éclaire le fait que RESTet HTTPsont souvent utilisées en tandem. Cela est principalement dû à la simplicité de HTTP et à sa correspondance très naturelle avec les principes RESTful.

Principes fondamentaux de REST

Communication client-serveur

Les architectures client-serveur ont une séparation très distincte des préoccupations. Toutes les applications construites dans le style RESTful doivent également être en principe client-serveur.

Apatride

Chaque demande client au serveur nécessite que son état soit entièrement représenté. Le serveur doit être en mesure de comprendre complètement la demande du client sans utiliser de contexte de serveur ou d'état de session de serveur. Il s'ensuit que tout état doit être conservé sur le client.

Cacheable

Des contraintes de cache peuvent être utilisées, permettant ainsi aux données de réponse d'être marquées comme pouvant être mises en cache ou non. Toutes les données marquées comme pouvant être mises en cache peuvent être réutilisées comme réponse à la même demande ultérieure.

Interface uniforme

Tous les composants doivent interagir via une seule interface uniforme. Étant donné que toutes les interactions entre les composants se produisent via cette interface, l'interaction avec différents services est très simple. L'interface est la même! Cela signifie également que les modifications d'implémentation peuvent être effectuées isolément. De tels changements n'affecteront pas l'interaction fondamentale des composants car l'interface uniforme est toujours inchangée. Un inconvénient est que vous êtes coincé avec l'interface. Si une optimisation peut être fournie à un service spécifique en modifiant l'interface, vous n'avez pas de chance car REST l'interdit. Du côté positif, cependant, REST est optimisé pour le Web, d'où une popularité incroyable de REST sur HTTP!

Les concepts ci-dessus représentent la définition des caractéristiques de REST et différencient l'architecture REST des autres architectures comme les services Web. Il est utile de noter qu'un service REST est un service Web, mais un service Web n'est pas nécessairement un service REST.

Voir ce blog post sur REST Principes de conception pour plus de détails sur REST et les points ci - dessus mentionnées.

EDIT: mettre à jour le contenu en fonction des commentaires

cmd
la source
7
REST n'a pas un ensemble prédéfini d'opérations qui sont des opérations CRUD. Le mappage aveugle des méthodes HTTP aux opérations CRUD est l'une des idées fausses les plus courantes autour de REST. Les méthodes HTTP ont des comportements très bien définis qui n'ont rien à voir avec CRUD, et REST n'est pas couplé à HTTP. Vous pouvez avoir une API REST sur ftp avec rien d'autre que RETR et STOR, par exemple.
Pedro Werneck
10
Aussi, que voulez-vous dire par «les services REST sont idempotents»? Pour autant que je sache, vous avez des méthodes HTTP qui par défaut sont idempotentes, et si une opération particulière de votre service a besoin d'idempotence, vous devez les utiliser, mais cela n'a pas de sens de dire que le service est idempotent. Le service peut avoir des ressources avec des actions qui peuvent être effectuées de manière idempotente ou non idempotente.
Pedro Werneck
2
@cmd: veuillez supprimer le quatrième point - "Une architecture RESTful peut utiliser HTTP ou SOAP comme protocole de communication sous-jacent". c'est une désinformation que vous transmettez.
Bruce_Wayne
238

SOAP ( Simple Object Access Protocol ) et REST ( Representation State Transfer ) sont tous deux beaux à leur manière. Je ne les compare donc pas. Au lieu de cela, j'essaie de représenter l'image, quand j'ai préféré utiliser REST et quand SOAP.

Qu'est-ce que la charge utile?

Lorsque des données sont envoyées sur Internet, chaque unité transmise comprend à la fois des informations d'en-tête et les données réelles envoyées. L'en-tête identifie la source et la destination du paquet, tandis que les données réelles sont appelées la charge utile . En général, la charge utile est les données qui sont transportées pour le compte d'une application et les données reçues par le système de destination.

Maintenant, par exemple, je dois envoyer un télégramme et nous savons tous que le coût du télégramme dépendra de quelques mots.

Alors dites-moi parmi les deux messages mentionnés ci-dessous, lequel est le moins cher à envoyer?

<name>Arin</name>

ou

"name": "Arin"

Je sais que votre réponse sera la deuxième, bien que les deux représentant le même message soient moins chers en termes de coût.

J'essaie donc de dire que l' envoi de données sur le réseau au format JSON est moins cher que l'envoi au format XML concernant la charge utile .

Voici le premier ou les premiers avantages de REST par rapport à SOAP . SOAP ne prend en charge que XML, mais REST prend en charge différents formats comme le texte, JSON, XML, etc. Et nous savons déjà que si nous utilisons Json, nous serons certainement mieux placés en ce qui concerne la charge utile.

Maintenant, SOAP prend en charge le seul XML, mais il a aussi ses avantages.

Vraiment! Comment?

SOAP s'appuie sur XML de trois manières Enveloppe - qui définit ce qui est dans le message et comment le traiter.

Un ensemble de règles de codage pour les types de données, et enfin la disposition des appels de procédure et des réponses recueillies.

Cette enveloppe est envoyée via un transport (HTTP / HTTPS), et un RPC (Remote Procedure Call) est exécuté, et l'enveloppe est retournée avec des informations dans un document au format XML.

Le point important est que l' un des avantages de SOAP est l'utilisation du transport «générique» mais REST utilise HTTP / HTTPS . SOAP peut utiliser presque n'importe quel moyen de transport pour envoyer la demande, mais REST ne le peut pas. Nous avons donc ici l'avantage d'utiliser SOAP.

Comme je l'ai déjà mentionné dans le paragraphe ci-dessus "REST utilise HTTP / HTTPS" , alors approfondissez un peu ces mots.

Lorsque nous parlons de REST sur HTTP, toutes les mesures de sécurité appliquées HTTP sont héritées, ce qui est connu sous le nom de sécurité au niveau du transport et il sécurise les messages uniquement lorsqu'il est à l'intérieur du câble, mais une fois que vous l'avez remis de l'autre côté, vous ne savez pas combien d'étapes il devra franchir avant d'atteindre le point réel où les données seront traitées. Et bien sûr, toutes ces étapes pourraient utiliser quelque chose de différent de HTTP. Le repos n'est donc pas complètement plus sûr, non?

Mais SOAP prend en charge SSL tout comme REST et prend également en charge WS-Security, qui ajoute des fonctionnalités de sécurité d'entreprise. WS-Security offre une protection de la création du message à sa consommation . Donc, pour la sécurité au niveau du transport, quelle que soit la faille que nous ayons trouvée, elle peut être évitée à l'aide de WS-Security.

En dehors de cela, comme REST est limité par son protocole HTTP, sa prise en charge des transactions n'est donc pas conforme à ACID et ne peut pas fournir de validation en deux phases sur les ressources transnationales distribuées.

Mais SOAP prend en charge à la fois la gestion des transactions basée sur ACID pour les transactions de courte durée et la gestion des transactions basée sur la compensation pour les transactions de longue durée. Il prend également en charge la validation en deux phases sur les ressources distribuées .

Je ne tire aucune conclusion, mais je préférerai un service Web basé sur SOAP alors que la sécurité, la transaction, etc. sont les principales préoccupations.

Voici le "Tutoriel Java EE 6" où ils ont dit qu'une conception RESTful peut être appropriée lorsque les conditions suivantes sont remplies . Regarde.

J'espère que vous avez apprécié la lecture de ma réponse.

Les bactéries
la source
15
Excellente réponse, mais n'oubliez pas que REST peut utiliser n'importe quel protocole de transport. Par exemple, il peut utiliser FTP.
Bhargav Nanekalva
11
Qui a dit que REST ne pouvait pas utiliser SSL?
Osama Aftab
1
@ Osama Aftab REST prend en charge SSL, mais SOAP prend en charge SSL tout comme REST et prend également en charge WS-Security.
Bactéries
3
Pour référencer le point sur la taille des données XML, lorsque la compression est activée, XML est assez petit.
GaTechThomas
2
Le point sur la taille de la charge utile doit être supprimé, il s'agit d'une telle comparaison unidimensionnelle entre JSON et XML et n'est possible de détecter que dans des configurations sérieusement optimisées, qui sont très éloignées.
ThomasRS
127

REST ( RE présentation S tate T ransfert)
RE présentation S tate d'un objet est T ransferred est REST à dire que nous ne objet pas envoyé, nous envoyons l' état d'objet. REST est un style architectural. Il ne définit pas autant de normes comme SOAP. REST sert à exposer des API publiques (par exemple, Facebook API, Google Maps API) sur Internet pour gérer les opérations CRUD sur les données. REST se concentre sur l'accès aux ressources nommées via une seule interface cohérente.

SOAP ( S œuvre O bjet A ccess P ROTOCOLE)
SOAP apporte son propre protocole et se concentre sur l' exposition des pièces de la logique d'application (pas de données) que des services. SOAP expose les opérations. SOAP se concentre sur l'accès aux opérations nommées, chaque opération implémentant une logique métier. Bien que SOAP soit communément appelé services Web, ce terme est inapproprié. SOAP a très peu sinon rien à voir avec le Web. REST fournit de véritables services Web basés sur les URI et HTTP.

Pourquoi REST?

  • Étant donné que REST utilise HTTP standard, il est beaucoup plus simple à peu près jamais.
  • REST est plus facile à implémenter, nécessite moins de bande passante et de ressources.
  • REST autorise de nombreux formats de données différents alors que SOAP n'autorise que XML.
  • REST permet une meilleure prise en charge des clients de navigateur en raison de sa prise en charge de JSON.
  • REST offre de meilleures performances et évolutivité. Les lectures REST peuvent être mises en cache, les lectures basées sur SOAP ne peuvent pas être mises en cache.
  • Si la sécurité n'est pas une préoccupation majeure et que nous avons des ressources limitées. Ou nous voulons créer une API qui sera facilement utilisée publiquement par d'autres développeurs, alors nous devrions opter pour REST.
  • Si nous avons besoin d'opérations CRUD sans état, optez pour REST.
  • REST est couramment utilisé dans les médias sociaux, le chat Web, les services mobiles et les API publiques comme Google Maps.
  • Le service RESTful renvoie divers MediaTypes pour la même ressource, selon le paramètre d'en-tête de demande "Accept" comme application/xmlou application/jsonpour POST et /user/1234.jsonou GET /user/1234.xmlpour GET.
  • Les services REST sont destinés à être appelés par l'application côté client et non directement par l'utilisateur final.
  • ST en reste provient de S tate T ransfert. Vous transférez l'état autour au lieu de le stocker sur le serveur, ce qui rend les services REST évolutifs.

Pourquoi SOAP?

  • SOAP n'est pas très facile à implémenter et nécessite plus de bande passante et de ressources.
  • La demande de message SOAP est traitée plus lentement que REST et n'utilise pas de mécanisme de mise en cache Web.
  • WS-Security: Alors que SOAP prend en charge SSL (tout comme REST), il prend également en charge WS-Security qui ajoute certaines fonctionnalités de sécurité d'entreprise.
  • WS-AtomicTransaction: Besoin de transactions ACID sur un service, vous allez avoir besoin de SOAP.
  • WS-ReliableMessaging: si votre application a besoin d'un traitement asynchrone et d'un niveau de fiabilité et de sécurité garanti. Rest n'a pas de système de messagerie standard et attend des clients qu'ils gèrent les échecs de communication en réessayant.
  • Si la sécurité est une préoccupation majeure et que les ressources ne sont pas limitées, nous devons utiliser les services Web SOAP. Comme si nous créons un service Web pour les passerelles de paiement, les travaux liés aux finances et aux télécommunications, nous devrions opter pour SOAP car ici une haute sécurité est nécessaire.

entrez la description de l'image ici

source1
source2

Premraj
la source
Les verbes / méthodes REST n'ont pas de relation 1 à 1 avec les méthodes CRUD bien que cela puisse aider au début à comprendre le style REST.
Santiago Martí Olbrich
5
REST ne prend pas en charge SSL? l'url de ressource uniforme pour le repos ne peut pas commencer par https: //?
Mou
51

Différence entre le repos et le savon

SAVON

  1. SOAP est un protocole.
  2. SOAP signifie Simple Object Access Protocol.
  3. SOAP ne peut pas utiliser REST car il s'agit d'un protocole.
  4. SOAP utilise des interfaces de services pour exposer la logique métier.
  5. SOAP définit des normes à respecter strictement.
  6. SOAP nécessite plus de bande passante et de ressources que REST.
  7. SOAP définit sa propre sécurité.
  8. SOAP autorise uniquement le format de données XML.
  9. SOAP est moins préféré que REST.

DU REPOS

  1. REST est un style architectural.
  2. REST signifie Representational State Transfer.
  3. REST peut utiliser les services Web SOAP car c'est un concept et peut utiliser n'importe quel protocole comme HTTP, SOAP.
  4. REST utilise l'URI pour exposer la logique métier.
  5. REST ne définit pas trop de normes comme SOAP.
  6. REST nécessite moins de bande passante et de ressources que SOAP.
  7. Les services Web RESTful héritent des mesures de sécurité du transport sous-jacent.
  8. REST permet différents formats de données tels que le texte brut, HTML, XML, JSON, etc.
  9. REST est plus préféré que SOAP.

Pour plus de détails, veuillez voir ici

Rex
la source
Les 3 et 6 sous REST ne sont-ils pas contradictoires?
Drazen Bjelovuk
Nous comparons simplement les caractéristiques les uns des autres.
Rex
21

À mon humble avis, vous ne pouvez pas comparer SOAP et REST où ce sont deux choses différentes.

SOAP est un protocole et REST est un modèle architectural logiciel. Il y a beaucoup d'idées fausses sur Internet pour SOAP vs REST .

SOAP définit le format de message basé sur XML que les applications activées pour les services Web utilisent pour communiquer entre elles sur Internet. Pour ce faire, les applications nécessitent une connaissance préalable du contrat de message, des types de données, etc.

REST représente l'état (en tant que ressources) d'un serveur à partir d'une URL. Il est sans état et les clients ne doivent pas avoir de connaissances préalables pour interagir avec le serveur au-delà de la compréhension de l'hypermédia.

marvelTracker
la source
15

Tout d' abord: officiellement, serait la bonne question web services + WSDL + SOAPvs REST.

Parce que, bien que le service Web soit utilisé au sens large, lors de l'utilisation du protocole HTTP pour transférer des données au lieu de pages Web, il s'agit officiellement d' une forme très spécifique de cette idée. Selon la définition, REST n'est pas un "service Web".

En pratique cependant, tout le monde l'ignore, alors ignorons-le aussi

Il y a déjà des réponses techniques, je vais donc essayer de fournir une certaine intuition.

Disons que vous voulez appeler une fonction dans un ordinateur distant, implémentée dans un autre langage de programmation (cela est souvent appelé appel de procédure distante / RPC ). Supposons que cette fonction se trouve à une URL spécifique, fournie par la personne qui l'a écrite. Vous devez (en quelque sorte) lui envoyer un message et obtenir une réponse. Il y a donc deux questions principales à considérer.

  • quel est le format du message que vous devez envoyer
  • comment faire passer le message d'avant en arrière

Pour la première question, la définition officielle est WSDL . Il s'agit d'un fichier XML qui décrit, dans un format détaillé et strict, quels sont les paramètres, quels sont leurs types, noms, valeurs par défaut, le nom de la fonction à appeler, etc. Un exemple WSDL ici montre que le fichier est humain -lisible (mais pas facilement).

Pour la deuxième question, il existe différentes réponses. Cependant, le seul utilisé dans la pratique est SOAP . Son idée principale est: envelopper le XML précédent (le message réel) dans un autre XML (contenant des informations d'encodage et d'autres trucs utiles), et l'envoyer via HTTP. La méthode POST du HTTP est utilisée pour envoyer le message, car il y a toujours un corps .

L'idée principale de toute cette approche est que vous mappez une URL à une fonction , c'est-à-dire à une action . Donc, si vous avez une liste de clients sur un serveur et que vous souhaitez afficher / mettre à jour / supprimer un, vous devez avoir 3 URL:

  • myapp/read-customer et dans le corps du message, passez l'id du client à lire.
  • myapp/update-customer et dans le corps, passez l'id du client, ainsi que les nouvelles données
  • myapp/delete-customer et l'id dans le corps

L'approche REST voit les choses différemment. Une URL ne doit pas représenter une action, mais une chose (appelée ressource dans le jargon REST). Étant donné que le protocole HTTP (que nous utilisons déjà) prend en charge les verbes, utilisez ces verbes pour spécifier les actions à effectuer sur la chose.

Ainsi, avec l'approche REST, le client numéro 12 se trouverait sur l'URL myapp/customers/12. Pour afficher les données client, vous appuyez sur l'URL avec une demande GET. Pour le supprimer, la même URL, avec un verbe DELETE. Pour le mettre à jour, encore une fois, la même URL avec un verbe POST et le nouveau contenu dans le corps de la demande.

Pour plus de détails sur les exigences qu'un service doit remplir pour être considéré comme vraiment RESTful, voir le modèle de maturité Richardson . L'article donne des exemples et, plus important encore, explique pourquoi un service (soi-disant) SOAP est un service REST de niveau 0 (bien que le niveau 0 signifie une faible conformité à ce modèle, il n'est pas offensant et il est toujours utile dans de nombreux cas).

note bleue
la source
Que voulez-vous dire RESTn'est pas un service Web ?? Quoi JAX-RSalors ??
Ashish Kamble
1
@AshishKamble: J'ai fourni le lien de la spécification des services de repos. La définition officielle ne contient que les protocoles WS- * (à peu près ceux que nous appelons "SOAP") et le repos n'en fait pas officiellement partie
blue_note
1
@AshishKamble: Notez également qu'il existe également un JAX-WS, qui signifie «services Web», différencié des «services de repos». Quoi qu'il en soit, la distinction n'est pas importante à des fins pratiques, comme je l'ai également noté.
blue_note
14

Parmi beaucoup d'autres déjà couverts dans les nombreuses réponses, je voudrais souligner que SOAP permet de définir un contrat, le WSDL, qui définit les opérations supportées, les types complexes, etc. SOAP est orienté vers les opérations, mais REST est orienté vers les ressources. Personnellement, je choisirais SOAP pour les interfaces complexes entre les applications d'entreprise internes et REST pour les interfaces publiques, plus simples et sans état avec le monde extérieur.

entrez la description de l'image ici

Jose Manuel Gomez Alvarez
la source
10

Ajout pour:

++ Une erreur qui est souvent commise à l'approche de REST est de le considérer comme des «services Web avec URL» - de penser à REST comme un autre mécanisme d'appel de procédure à distance (RPC), comme SOAP, mais invoqué via des URL HTTP simples et sans lourdeur de SOAP Espaces de noms XML.

++ Au contraire, REST n'a pas grand-chose à voir avec RPC. Alors que RPC est orienté services et concentré sur les actions et les verbes, REST est orienté ressources, mettant l'accent sur les choses et les noms qui composent une application.

Quan Nguyen
la source
9

Beaucoup de ces réponses ont complètement oublié de mentionner les contrôles hypermédia (HATEOAS) qui sont complètement fondamentaux pour REST. Quelques autres l'ont abordé, mais ne l'ont pas vraiment bien expliqué.

Cet article devrait expliquer la différence entre les concepts, sans entrer dans les mauvaises herbes sur des fonctionnalités SOAP spécifiques.

Phil Sturgeon
la source