SAVON vs RESTE (les différences)

REST vs SOAP est pas la bonne question à poser.

REST , contrairement à SOAP est pas un protocole.

REST est un style architectural et un design pour les architectures logicielles basées sur le réseau.

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

La question de @Abdulaziz met en lumière le fait que REST et HTTP sont souvent utilisés en tandem. Cela est principalement dû à la simplicité de HTTP et sa correspondance très naturelle avec les principes Reposful.

principes de repos fondamentaux

Communication Client-Serveur

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

apatrides

chaque requête client au serveur exige que son état soit pleinement représenté. Le serveur doit être capable de comprendre complètement la requête client sans utiliser le contexte du serveur ou l'état de session du serveur. Il s'ensuit que tout état doit être maintenu sur le client.

Cachable

Cache des contraintes peuvent être utilisées, permettant ainsi de marquer les données de réponse comme étant "cachables" ou "non-cachables". Toute donnée identifiée comme pouvant être mise en cache peut être réutilisée en tant que réponse à la même demande ultérieure.

Interface Uniforme

tous les composants doivent interagir au moyen d'une interface unique et uniforme. Comme toutes les interactions entre les composants se font via cette interface, l'interaction avec différents services est très simple. L'interface est la même! Cela signifie également que les changements de mise en œuvre peuvent être faits isolément. De tels changements, n'affecteront pas l'interaction fondamentale des composants parce que l'interface uniforme est toujours inchangée. Un désavantage est que vous êtes coincé avec l'interface. Si une optimisation peut être fournie à un service spécifique en changeant l'interface, vous n'avez pas de chance car le repos l'interdit. Côté positif, cependant, REST est optimisé pour le web, d'où une incroyable popularité de REST sur HTTP!

les concepts ci-dessus représentent les caractéristiques définissant le repos et distinguent l'architecture du repos d'autres architectures comme les services web. Il est utile de noter qu'un service REST est un service web, mais qu'un service web n'est pas nécessairement un service REST.

Voir ce blog post sur RESTE " Principes de Conception pour plus de détails sur RESTE et est indiquée ci-dessus balles.

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

SOAP ( Simple Object Access Protocol ) et de REPOS ( la Représentation de l'État de Transfert ), les deux sont belles à leur manière. Je ne suis donc pas les comparer. Au lieu de cela, j'essaie de dépeindre l'image, quand j'ai préféré utiliser le repos et quand le savon.

Qu'est-ce que la charge utile?

lorsque les données sont transmises par Internet, chaque unité transmise comprend à la fois l'en-tête les informations et les données effectivement transmises. 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 certains mot.

alors dites-moi parmi les 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 la deuxième est moins cher en ce qui concerne le coût.

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

voici le premier avantage ou les avantages du repos sur le savon . SOAP ne supporte que XML, mais REST supporte différents formats comme text, JSON, XML, etc. Et nous savons déjà, si nous utilisons Json alors certainement nous serons à un meilleur endroit en ce qui concerne la charge utile.

maintenant, SOAP supporte le seul XML, mais il a aussi ses avantages.

vraiment! Comment?

SOAP s'appuie sur XML de trois façons L'enveloppe qui définit ce qui est dans le message et comment le traiter.

un ensemble de règles d'encodage 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 en XML document mis en forme.

le point important est que l'un des avantages du savon est l'utilisation du " transport Générique mais reste utilise HTTP/HTTPS . SOAP peut utiliser presque n'importe quel transport pour envoyer la demande mais le reste ne peut pas. Nous avons donc l'avantage d'utiliser du savon.

comme je l'ai déjà mentionné dans le paragraphe ci-dessus "REST utilise HTTP/HTTPS" , donc aller un peu plus loin sur ces mots.

quand nous parlons de repos sur HTTP, toutes les mesures de sécurité appliquées HTTP sont héritées, et cela est connu comme niveau de sécurité de transport et il sécurise les messages seulement tandis que il est à l'intérieur du fil mais une fois que vous l'avez livré de l'autre côté, vous ne savez pas combien d'étapes il devra passer 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. donc le repos n'est pas complètement plus sûr, n'est-ce pas?

mais SOAP prend en charge SSL tout comme le reste en outre il prend également en charge WS-Security qui ajoute quelques caractéristiques de sécurité d'entreprise. WS-Security offre une protection contre la création du message à sa consommation . Donc, pour la sécurité des transports, quelle que soit la faille que nous avons trouvée et qui peut être évitée en utilisant WS-Security.

en outre, comme reste est limité par son protocole HTTP donc son support de transaction n'est pas compatible avec L'acide et ne peut pas fournir de commit en deux phases à travers des ressources transnationales distribuées.

mais SOAP a un soutien complet pour les deux gestion des transactions basée sur L'acide pour les transactions de courte durée et la gestion des transactions basée sur la rémunération pour les transactions de longue durée. Il prend également en charge deux-phase s'engager à travers les ressources distribuées .

Je ne tire aucune conclusion, mais je préfère un service Web SOAP tout en sécurité, transaction, etc. sont les principales préoccupations.

voici le " tutoriel Java EE 6 "où ils ont dit un design reposant peut être approprié lorsque les conditions suivantes sont remplies . Un coup d'oeil.

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

RESTE ( RE présentation S tate T ransfert)

Le repos est un style architectural. Il ne définit pas tant de normes comme le savon. REST est pour exposer les API publiques (i.e. API Facebook, API GoogleMaps) sur internet pour gérer les opérations CRUD sur les données. REST se concentre sur l'accès aux ressources nommées par le biais d'une seule interface cohérente.

SAVON de marseille ( S mise O objet Un accès P rotocol)

SOAP apporte son propre protocole et se concentre sur l'exposition de morceaux de logique d'application (Pas de données) en tant que services. Le savon expose les opérations. SOAP se concentre sur l'accès aux opérations nommées, chaque opération implémente une logique métier. Bien que SOAP est communément appelé services web ce est impropre. SOAP a très peu ou n'importe quoi à voir avec le Web. REST fournit true Web services basé sur URIs et HTTP.

pourquoi se reposer?

• étant donné que REST utilise le HTTP standard, il est beaucoup plus simple d'y parvenir.
• reste est plus facile à mettre en œuvre, nécessite moins de bande passante et de ressources.
• permet de nombreuses données différentes formats dans lesquels as SOAP ne permet que le XML.
• reste permet un meilleur soutien pour les clients de navigateur en raison de son soutien pour JSON.
• repos a une meilleure performance et évolutivité. Les autres lectures peuvent être mises en cache, les lectures à base de savon ne peuvent pas être mises en cache.
• si la sécurité n'est pas une préoccupation majeure et que nos ressources sont limitées. Ou nous voulons créer une API qui sera facilement utilisée par d'autres développeurs publiquement alors nous devrions aller avec REST.
• si nous avons besoin de crude opérations apatrides alors aller avec le repos.
• reste est couramment utilisé dans les médias sociaux, chat sur le web, les services mobiles et les API publiques comme Google Maps.
• service RESTful retour divers MediaTypes pour la même ressource, en fonction de la demande paramètre d'en-tête "Accept" comme application/xml ou application/json de la POSTE et des /user/1234.json ou OBTENIR des /user/1234.xml pour les OBTENIR.
• les services de repos sont visés d'être appelé par l'application côté client et non pas directement aux utilisateurs finaux.
• ST dans le RESTE provient de S tate T ransfert. Vous transférez l'état autour au lieu d'avoir le serveur le stocker, ce qui rend les services REST évolutif.

pourquoi du savon?

• SOAP n'est pas très facile à mettre en œuvre et nécessite plus de bande passante et de ressources.
La requête de message SOAP
• est traitée plus lentement que la requête REST et n'utilise pas de mécanisme de mise en cache web.
• WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which add some enterprise security features.
• WS-AtomicTransaction: besoin de Transactions acides sur un service, vous allez avoir besoin de savon.
• WS-ReliableMessaging: si votre application nécessite un traitement asynchrone et un niveau garanti de fiabilité et de sécurité. Rest ne dispose pas d'un système de messagerie standard et s'attend à ce que les clients règlent les problèmes de communication en effectuant des recherches.
• si la sécurité est une préoccupation majeure et que les ressources ne sont pas limitées, nous devrions utiliser les services web SOAP. Comme si nous créons un service web pour les passerelles de paiement, et le travail lié aux télécommunications alors nous devrions aller avec le savon car ici la haute sécurité est nécessaire.

source1

source 2

La décision entre les deux sera votre premier choix dans la conception d'un service web, il est important de comprendre les avantages et les inconvénients des deux. Il est également important, dans le débat parfois houleux entre les deux philosophies, de séparer la réalité de la rhétorique.

RESTE fondamentaux

• tout dans le repos est considéré comme une ressource.
• Chaque ressource est identifiée par un URI.
• utilise des interfaces uniformes. Les ressources sont gérées en utilisant des opérations POST, GET, PUT, DELETE qui sont similaires aux opérations Create, Read, Update et Delete (CRUD).
• être apatride. Chaque requête est une requête indépendante. Chaque requête du client au serveur doit contenir toutes les informations nécessaires pour comprendre la requête.
Les Communications
• se font par l'intermédiaire de représentations. Par exemple, XML, JSON RESTful Web Services. Web RESTful les services sont basés sur les méthodes HTTP et le concept de REST. Un service Web RESTful définit typiquement L'URI de base pour les services; les types MIME pris en charge (XML, texte, JSON, défini par l'utilisateur, ...) et l'ensemble des opérations (POST, GET, PUT, DELETE) qui sont supportées.

SAVON fondamentaux

• WSDL définit le contrat entre le client et le service et est statique de par sa nature.
• SOAP construit un protocole basé sur XML au dessus de HTTP ou parfois TCP/IP.
• SOAP décrit les fonctions et les types de données.
• SOAP est un successeur de XML-RPC et est très similaire, mais décrit une façon standard de communiquer.
• plusieurs langages de programmation ont un support natif pour SOAP, vous lui donnez généralement une URL de service web, et vous pouvez appeler ses fonctions de service web sans avoir besoin de code spécifique.
• Les données binaires qui sont envoyées doivent d'abord être encodées dans un format tel que base64 encodé.
• dispose de plusieurs protocoles et technologies relatifs à l'informatique: WSDL, XSD, SOAP, WS-Addressing.

SOAP vs REST?

L'un des principaux avantages de SOAP est que vous avez une description de service WSDL. Vous pouvez pratiquement découvrir le service automatiquement et générer un proxy de client Utilisable à partir de ce service description (générer les appels de service, les types de données nécessaires pour les méthodes et ainsi de suite). Notez qu'avec la version 2.0, WSDL prend en charge tous les verbes HTTP et peut être utilisé pour documenter les services RESTful, mais il existe une alternative moins verbeuse dans WADL (Web Application Description Language) à cet effet.

avec les services RESTful, la sécurité des messages est assurée par le protocole de transport (HTTPS) et n'est assurée que de point en point. Il n'a pas de système de messagerie standard et attend des clients qu'ils règlent les problèmes de communication en se rétractant. SOAP a la logique de succès/Rety intégré et fournit la fiabilité de bout en bout même à travers les intermédiaires SOAP.

L'un des principaux avantages de RESTful API est qu'il est flexible pour la représentation de données, par exemple, vous pouvez sérialiser vos données en format XML ou JSON. Les IPA reposants sont plus propres ou plus faciles à comprendre parce qu'ils ajoutent un élément d'utilisation des URI normalisés et donnent de l'importance à Le verbe HTTP utilisé (C'est-à-dire GET, POST, PUT et DELETE).

les services RESTful sont également légers, c'est-à-dire qu'ils n'ont pas beaucoup de balisage XML supplémentaire. Pour invoquer L'API RESTful tout ce dont vous avez besoin est un navigateur ou une pile HTTP et à peu près tous les périphériques ou machines connectés à un réseau ont cela.

avantages du repos

• depuis REST utilise HTTP standard, il est beaucoup plus simple dans à peu près tous les sens. Creating clients, développer des API, la documentation est beaucoup plus facile à comprendre, et il n'y a pas beaucoup de choses que REST ne fait pas plus facile/mieux que SOAP.
• 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é au repos parce que vous avez besoin de gérer les formats alternatifs et / ou substituts, d'après mon expérience, cela a été tout à fait bénéfique. JSON est généralement un meilleur ajustement pour les données et parses beaucoup plus rapide. Le repos permet une meilleure prise en charge du navigateur clients en raison de son soutien pour JSON.
Le repos
• a de meilleures performances et évolutivité. Les autres lectures peuvent être mises en cache; les lectures à base de savon ne peuvent pas être mises en cache.
• aucun outil coûteux ne nécessite d'interagir avec le service Web
• Small learning curve
• efficace (SOAP utilise XML pour tous les messages, le reste peut utiliser des formats de messages plus petits)
• Rapide (pas de vaste de traitement requis)
• de plus près à d'autres technologies du Web dans la philosophie de conception

avantages du savon

• WS-Security: While SOAP supports SSL (just like REST) it also supports WS-Security which adds some enterprise security features. Soutient l'identité par des intermédiaires, pas seulement point à point (SSL). Il fournit également une implémentation standard de l'intégrité des données et la confidentialité des données. L'appeler " entreprise "ne veut pas dire qu'elle est plus sûre, elle prend simplement en charge certains outils de sécurité dont les services internet typiques n'ont pas besoin, en fait, ils ne sont nécessaires que dans quelques scénarios" d'entreprise".
• WS-AtomicTransaction: besoin de Transactions acides sur un service, vous allez avoir besoin de savon. Tandis que REST supporte les transactions, il n'est pas aussi complet et N'est pas conforme à L'ACID. Heureusement, les transactions acides n'ont presque jamais de sens Internet. REST est limité par HTTP lui-même qui ne peut pas fournir de commit en deux phases à travers les ressources transactionnelles distribuées, mais SOAP le peut. Les applications Internet n'ont pas besoin de ce niveau de fiabilité transactionnelle, les applications d'entreprise en ont parfois besoin.
• WS-ReliableMessaging: Rest n'a pas de système de messagerie standard et attend des clients qu'ils règlent les problèmes de communication en effectuant des recherches. SOAP a une logique de réussite/réessaiement intégrée et offre une fiabilité de bout en bout même par des intermédiaires SOAP.
• de la Langue, de plateforme, et de transport indépendant (RESTE nécessite l'utilisation de HTTP)
• fonctionne bien dans les environnements d'entreprise distribués (le reste suppose une communication directe point à point)
• standardisé
• fournit une extensibilité pré-construction importante sous la forme des normes WS
• traitement intégré des erreurs
• lors de l'Automatisation utilisé avec certains produits linguistiques

Où utiliser REST

les zones pour lesquelles le repos fonctionne bien sont:

• bande passante et ressources limitées: rappelez-vous que la structure de retour est vraiment dans n'importe quel format (défini par le développeur). De plus, n'importe quel navigateur peut être utilisé parce que L'approche REST utilise les verbes standard GET, PUT, POST et DELETE. Encore une fois, rappelez-vous que le repos peut utilisez également L'objet XMLHttpRequest que la plupart des navigateurs modernes prennent en charge aujourd'hui, ce qui ajoute un bonus D'AJAX.
• apatrides opérations: si une opération doit être poursuivie, puis REPOS n'est pas la meilleure approche et de SAVON peut l'adapter le mieux. Cependant, si vous avez besoin d'opérations stateless CRUD (Create, Read, Update, and Delete), le reste est fait.
• mise en Cache des situations: si l'information peut être mis en cache en raison de le fonctionnement sans état de l'approche repos, c'est parfait.

Où utiliser du savon

zones où le savon fonctionne comme une grande solution:

• traitement asynchrone et invocation: si votre application nécessite un niveau garanti de fiabilité et de sécurité, alors SOAP 1.2 offre des normes supplémentaires pour assurer ce type d'opération. Des choses comme WSRM – WS-messagerie fiable.
• contrats Formels: si les deux parties (fournisseur et le consommateur) se mettre d'accord sur le format d'échange puis SOAP 1.2 donne les strictes spécifications pour ce type d'interaction.
• opérations Stateful: si l'application nécessite des informations contextuelles et la gestion de l'état conversationnel, alors SOAP 1.2 A la spécification supplémentaire dans la structure WS pour soutenir ces choses (Sécurité, Transactions, Coordination, etc.)). Comparativement, l'approche de repos ferait les développeurs construire cette plomberie personnalisée.

différence entre le repos et le savon

savon

1. SOAP est un protocole.
2. SOAP signifie Simple Object Access Protocol.
3. savon ne peut pas utiliser le repos parce que c'est un protocole.
4. SOAP utilise des interfaces de services pour exposer la logique de l'entreprise.
5. SOAP définit les normes à respecter strictement.
6. Le SOAP nécessite plus de bande passante et de ressources que le REST.
7. SOAP définit sa propre sécurité.
8. SOAP permet le format de données XML seulement.
9. savon est moins préférable que le repos.

reste

1. REST est un style d'architecture.
2. reste signifie transfert D'État de représentation.
3. reste peut utiliser la toile de savon services parce que c'est un concept et peut utiliser N'importe quel protocole comme HTTP, SOAP.
4. reste utilise URI pour exposer la logique des affaires.
5. reste ne définit pas trop de normes comme le savon.
6. reste nécessite moins de bande passante et de ressources que SOAP.
7. RESTful web services hérite des mesures de sécurité du transport sous-jacent.
8. reste permet un format de données différent tel que le texte simple, HTML, XML, JSON etc.
9. reste plus préférable que le savon.

pour plus de détails voir ici

IMHO vous ne pouvez pas comparer le savon et le repos où ce sont deux choses différentes.

SAVON de marseille est un protocole et RESTE est un logiciel d'architecture modèle. Il y a beaucoup d'idées fausses sur internet pour SOAP vs REST .

SOAP définit le format de message fondé sur le XML que les applications Web compatibles avec les services utilisent pour communiquer entre elles au cours de la Internet. Pour ce faire, les applications doivent avoir 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 apatride 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.

Addition pour:

++ une erreur qui est souvent faite en approchant le REST est de le considérer comme des "services web avec URLs" - de penser au REST comme un autre mécanisme d'appel de procédure à distance (RPC), comme le SOAP, mais invoqué par le biais d'URLs HTTP simples et sans les espaces de noms XML volumineux de SOAP.

++ au contraire, REST a peu à voir avec RPC. Tandis que le RPC est axé sur le service et se concentre sur les actions et les verbes, le reste est axé sur les ressources, mettant l'accent sur les les choses et les noms qui constituent une demande.

parmi tant d'autres déjà couverts dans les nombreuses réponses, je voudrais souligner que SOAP permet de définir un contrat, la WSDL, qui définit les opérations prises en charge, les types complexes, etc. Le SOAP est orienté vers les opérations, mais le reste 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, apatrides avec le monde extérieur.

beaucoup de ces réponses ont complètement oublié de mentionner les contrôles hypermédia (HATEOAS) qui est tout à fait fondamental au repos. Quelques autres l'ont abordé, mais ne l'ont pas très bien expliqué.

cet article devrait expliquer la différence entre les concepts, sans entrer dans les mauvaises herbes sur les caractéristiques spécifiques du savon.

• SOAP is a protocol while REST is architecture.
• SOAP expose les comportements qui représentent la logique tandis que REST expose les ressources qui représentent les données.
• en termes de service de repos de consommation est beaucoup plus simple que le savon. Avec le repos, la gestion des enveloppes XML est éliminée, ce qui le rend plus rapide que le savon.
• SOAP a fourni de bonnes options de sécurité par rapport au repos.
• For machine to machine interaction & enterprise solutions SOAP is preferable but for public facing API 'REST is best option almost 70% public API' are REST.
• RESTE est léger, maintenable et évolutif.
• REST est indépendant de l'appareil, C'est-à-dire que le client consomme REST L'API peut être n'importe quoi comme les appareils mobiles, les ordinateurs portables, la télévision, etc.
• avec le nuage de venir en action. Application se déplace lentement vers les systèmes basés sur le nuage tels que Azure, Amazon AWS. Ces systèmes sont construits et exposent les API REST. C'est donc une bonne chose de construire l'application sur le dessus de L'API REST.

repos Vs savon

tout D'abord: dans le sens large, service web signifie utiliser le protocole HTTP pour transférer données au lieu de pages web. Cependant, dans le sens strict , un service web, tel que défini par W3C est une forme très spécifique de cette idée. Donc, quand les gens parlent de SOAP vs. REST , ils signifient en fait services web vs. REST (où "services web" se réfère à la définition officielle, puisque, dans la pratique, les services de repos sont également appelés services web par tout le monde).

donc, disons que vous voulez appeler une fonction dans un ordinateur distant, implémentée dans un autre langage de programmation ( remote procedure call/RPC ). Vous devez (d'une manière ou d'une autre) lui envoyer un message et obtenir une réponse. Tout d'abord, cette fonction peut être trouvée à une URL spécifique, fournie par son créateur. Ensuite, il y a deux questions principales à examiner.

• Quel est le format du message que vous devez envoyer
• comment devrait être le message porté avant en arrière

selon la définition officielle, la réponse à la première question Est la WSDL , un 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. À l' deuxième question, il y a plusieurs réponses. Le plus populaire (de loin) est savon . Son idée principale est: envelopper le XML précédent (le message réel) dans un autre XML, et l'envoyer par HTTP (bien que, en théorie, il peut être utilisé avec d'autres protocoles, mais personne ne le fait jamais). La méthode POST Du HTTP est utilisée pour envoyer le message, puisqu'il y a toujours un corps.

ainsi, par l'approche (largement, mais erronément) appelée SOAP, vous mappez une URL à un fonction, c'est-à-dire une action . L'approche RESTful est: au lieu de L'URL représentant une action, elle devrait représenter une chose (appelé ressource dans le jargon RESTful). Puisque le protocole HTTP (que nous utilisons déjà) supporte les verbes, utilisez ces verbes pour spécifier les actions à effectuer sur la chose.

donc, avec L'approche SOAP (encore une fois, mauvais terme), si vous avez une liste des clients, et vous voulez voir/Mettre à jour/supprimer un, vous aurez 3 URLS:

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

alors que, avec l'approche REST, vous auriez seulement myapp/customers/3 (où 3 est l'identification d'un client spécifique). Pour visualiser les données du client, vous cliquez sur L'URL avec une requête GET. Pour le supprimer, la même URL , avec un verbe supprimer. Pour le mettre à jour, à nouveau, la même URL avec un verbe POST, et le nouveau contenu dans le corps de la requête.

pour plus de détails sur les exigences qu'un service doit remplir pour être considéré comme véritablement reposant, voir le Richardson maturity model . L'article donne des exemples, et, plus important encore, explique pourquoi un (soi-disant) service SOAP, est un service de repos de niveau 0 (Bien que, Niveau 0 signifie faible conformité à ce modèle, il n'est pas offensant, et il est encore utile dans de nombreux cas).