Question sur les web services
Résolu
Rune188
Messages postés
65
Date d'inscription
Statut
Membre
Dernière intervention
-
Rune188 Messages postés 65 Date d'inscription Statut Membre Dernière intervention -
Rune188 Messages postés 65 Date d'inscription Statut Membre Dernière intervention -
A voir également:
- Question sur les web services
- Web office - Guide
- Navigateur web - Guide
- Création site web - Guide
- K9 web protection - Télécharger - Contrôle parental
- Adresse web exemple - Guide
2 réponses
Bonjour,
"pour les SOAP: si on fait une modification du côté du client ou du serveur, il faudra effectuer des modifications et mettre à jour de l’autre côté"
Non, c'est faux. Il faut distinguer le contrat du web service (ses méthodes, paramètres et résultats) de son implémentation.
Que ce soit en SOAP ou en REST tant que le contrat n'est pas modifié tu peux modifier l'implémentation autant que tu veux, le client arrivera à t'appeler et comprendre la réponse.
En revanche si tu supprimes ou modifies une méthode, que tu ajoutes des paramètres obligatoires, etc. le client devra se mettre à jour car il ne pourra pas communiquer avec le serveur en utilisant l'ancienne version du contrat.
"SOAP est un protocole et REST un style d'architecture"
Je ne trouve pas cette affirmation pertinente, puisque les deux se basent généralement sur le protocole HTTP (d'ailleurs on pourrait très bien "s'amuser" à décrire un contrat SOAP avec un serveur REST)
La différence entre les deux, c'est dans la manière d'utiliser le protocole HTTP.
Avec SOAP on fera toujours un POST vers la même URL (celle du contrat), le choix de la méthode utilisée et de ses paramètres est alors décrit dans le corps du message (en XML) et la réponse sera toujours en XML, y compris pour les messages d'erreur.
Avec REST on est beaucoup plus souple, on peut faire des POST comme SOAP, mais aussi n'importe quel autre verbe HTTP (notamment GET), le choix de la méthode - et éventuellement certains paramètres- se fait dans l'URL appelée (qui n'est donc plus obligatoirement unique), le corps du message et de la réponse peuvent être dans n'importe quel format, c'est souvent du JSON, mais rien n'empêche de faire du XML comme SOAP.
"pour les SOAP: si on fait une modification du côté du client ou du serveur, il faudra effectuer des modifications et mettre à jour de l’autre côté"
Non, c'est faux. Il faut distinguer le contrat du web service (ses méthodes, paramètres et résultats) de son implémentation.
Que ce soit en SOAP ou en REST tant que le contrat n'est pas modifié tu peux modifier l'implémentation autant que tu veux, le client arrivera à t'appeler et comprendre la réponse.
En revanche si tu supprimes ou modifies une méthode, que tu ajoutes des paramètres obligatoires, etc. le client devra se mettre à jour car il ne pourra pas communiquer avec le serveur en utilisant l'ancienne version du contrat.
"SOAP est un protocole et REST un style d'architecture"
Je ne trouve pas cette affirmation pertinente, puisque les deux se basent généralement sur le protocole HTTP (d'ailleurs on pourrait très bien "s'amuser" à décrire un contrat SOAP avec un serveur REST)
La différence entre les deux, c'est dans la manière d'utiliser le protocole HTTP.
Avec SOAP on fera toujours un POST vers la même URL (celle du contrat), le choix de la méthode utilisée et de ses paramètres est alors décrit dans le corps du message (en XML) et la réponse sera toujours en XML, y compris pour les messages d'erreur.
Avec REST on est beaucoup plus souple, on peut faire des POST comme SOAP, mais aussi n'importe quel autre verbe HTTP (notamment GET), le choix de la méthode - et éventuellement certains paramètres- se fait dans l'URL appelée (qui n'est donc plus obligatoirement unique), le corps du message et de la réponse peuvent être dans n'importe quel format, c'est souvent du JSON, mais rien n'empêche de faire du XML comme SOAP.
Peux tu m'indiquer ce qu'est le contrat ? Par quelle élément est il représenté dans mon projet ?
C'est quelque chose qui peut se générer automatiquement. Il y a différents formats mais les plus courants (a minima dans le monde Java) sont WSDL pour le SOAP et Swagger pour le REST.
En partageant le contrat auprès des clients du web service cela leur permettra de générer le code correspondant selon leur technologie.
https://www.w3schools.com/xml/xml_wsdl.asp
https://petstore.swagger.io/