Développez-vous plus des services Web SOAP ou REST, venez partager votre expérience ?

Dans le cadre du développement de services Web, deux familles peuvent être distinguées. La première basée sur des standards, appelée services Web SOAP ou étendu, s'appuie sur le triptyque WSDL, SOAP et UDDI. La seconde famille appelée service Web REST ou RESTful est un style d'architecture inspiré de l'architecture du Web.

Nous aimerions profiter de ce débat afin que vous veniez partager votre expérience dans la mise en place de services Web au sein des entreprises. Vous pourriez par exemple indiquer si dans le cas d'échange de données entre des entreprises, vous êtes plus amenés à utiliser les services Web SOAP pour les aspects standardisations ? De la même façon dans le cas d'ouverture d'API, êtes-vous plus enclins à développer des services Web REST ?

Nous avons également ajouté un petit sondage afin que vous puissiez choisir entre services Web SOAP, services Web REST ou pourquoi pas les deux.

Alors êtes-vous plus services Web SOAP ou service Web REST ?

Si je dois développer des web services dans un contexte B2B avec éventuellement des protocoles autres que HTTP; ou on doit gérer la problématique de gouvernance (standards ws-*), alors j'opterai pour des web services SOAP.

Si en revanche mes services sont exposés sur le web (protocole HTTP), alors je partirai sur du SOAP pour commencer simple.

SOAP c'est quand même quelque chose de lourd par rapport au RestFull ( nom compliqué pour dire get/post ).
Donc tout dépand de la taille du projet, des objectifs, de l'utilisation qu'on veux en faire, etc ...
C'est pas forcement une question de préfèrence. Le SOAP s'impose presque de lui même quand le projet prends de l'importance.

Bonjour,

Ayant employé pas mal de WS SOAP, j'ai rencontré dans au moins la moitiée de mes projets des soucis d'inter-opérabilité entre PHP et .net,

ce qui fait que, pour mes nouveaux WS, je n'emploie que du REST (sans aller jusqu’à faire du PUT ou autre, afin de pouvoir les tester simplement dans un navigateur)

J'utilise quasiment exclusivement du REST, de préférence RESTful.
C'est léger, simple, efficace.

Restful chaque fois que je le peux !

Comme d'autres j'ai déjà eu également des soucis entre PHP et webservices SOAP .Net.

Comme dit plus haut, c'est vraiment les besoins qui doivent driver ce choix. Si c'est pour mettre en place un flux entre deux applis métier, SOAP avec tout son outillage permet de faire des choses robustes efficacement (avec des générateurs etc... ). En plus les middleware / ETL / ESB le gère plutôt bien.

Par contre, pour le WEB/front, c'est vrai que des appels GET sur du JSON, c'est très efficace :) !

Pour moi c'est vraiment deux technos pour deux usages différents.

En fait je vois plutôt cela comme ça:

J'utilise ResT si je veux exposer mon API a un client il est plus efficace dans le cas d'intercommunication entre l'API et le client.

Le SOAP me semble plus approprié pour les communications entre serveur, il est plus difficile d'exposer les données SOAP que ResT.

Je crois donc au final que les deux types de service sont très efficace mais que chacun a son utilité propre.

Je veux envoyer les données d'un serveur a un autre pour quelque raison que ce soit j'utilise SOAP.

Je veux exposer un API et donner au client accès à des données stocké sur mon serveur sur son navigateur j'utilise ResT

Entre REST et SOAP c'est l'utilisation finale qui dicte ce que l'on veut faire.

SOAP est bien plus structuré grâce aux wdsl et l'uddi donc c'est pas mal pour du B2B.

REST est lui bien plus simple et léger (pas d'enveloppe XML).
Niveau sécurité si on utilise bien les possibilités du protocole HTTP via le HTTPS et authentification (forte ou faible), c'est aussi bien sécurité que SOAP avec WS-Security.

Personnellement je travaille sur des webservice orienté web et mobile et le choix a été vite fait : REST !
Il ne manque plus qu'un peu de formalisme à sa mise en place, notamment avec le wsdl2.

Comment est-il possible de faire du REST quand on ne peut pas envoyer des requêtes PUT et DELETE depuis le navigateur ?

Je connais que SOAP, mais le REST m'intèresse de plus en plus et apparament, cette techno est plutôt bien appréciée.

M'étant fait convertir par un développeur de très haute qualité, je dois reconnaitre que php + js + rest / json permet de faire des architectures très clean et très propre.

En tous cas, par rapport à WS ce n'est pas une référence puisqu'il s'agit souvent de tokens et contrôle de session, donc c'est plutôt des implémentations particuliéres. Pour le cas du xml, n'importe qui ayant bossé sur des vraies architectures distribuées (pas un WCF pour sauvegarder un objet dans une base); ils ont vite compris l'inutile lourdeur de la chose - et par extension SOAP...

En dehors de la découverte et de l'annuaire, qui ne sont pas si usités, je ne vois pas vraiment l'utilité.

Après comme chacun a sa sensibilité à ce qui fait une bonne application...Moi le soap et au dessus tout ce qui est ws est un fantasme de technocrates souvent inapplicable ou trop lourd à mettre en oeuvre.

Quand j'ai commencé a développer pour le Web, je venais du monde Windows et COM, j'ai donc naturellement utiliser SOAP dont le modèle m'était familier. C'est après avoir étudié le fonctionnement du SOAP plus en détail, que je me suis intéressé de plus près http et que j'ai découvert le style d'architecture REST.

Même s'il m'a fallu du temps pour en comprendre le principe (mes premières tentatives n'étaient que de mauvaises copies de SOAP), je suis aujourd'hui convaincu par REST même si l'authentification et la gestion des droits d'accès aux ressource sont encore des problèmes que je ne maîtrise pas totalement (https est une solution simple, mais parfois trop simpliste et qui empêche de tirer partie des caches).

REST, c'est bien moins lourd, plus simple à mettre en oeuvre et même plus performant si on utilise du JSON, puisque ça permet de diminuer la masse de données à transmettre.

Pour les WS Rest, il y a un contrat qui peut spécifier/éclaircir l'utilisation des service, grâce au WADL :
https://www.google.fr/search?q=rest+wadl

Dans le cadre d'une informatique d'entreprise SOA, et notamment pour la prise en charge aisée des format SOAP dans des ESB ou des outils similaires de middleware, SOAP reste à mon avis la meilleure solution pour les architectures complexes. D'ailleurs là où je travaille, on ne parle pas du tout de REST et ce n'est même pas envisagé.

Dans le cadre d'API web, REST me paraît nettement plus adapté, plus léger, plus facile à mettre en oeuvre.

Je répète en gros ce qui a déjà été dis à de nombreuses reprises avant, un consensus assez fort semble être acquis en matière de forces et faiblesses des deux technologies ;)

Pour commencer, j'adhère à la majorité des commentaires --> SOAP pour une communication serveur à serveur, REST pour un usage entre client et serveur (et pas seulement lorsqu'il s'agit d'un client web).

Ensuite, je trouve intéressant que ce post se trouve dans la rubrique Java. La raison est aussi le principal défaut de SOAP: C'est LE format Java, c'est à dire que c'est l'option que l'on trouvera systématiquement dans une implémentation Java, d'autres parfois mais pas toujours, et par opposition, le support de SOAP est relativement rare sur les produits développés sur d'autres plateformes.

Mort aux solutions propriétaires, vive SOAP et REST.

Citation:

---

Envoyé par Farid63

Comment est-il possible de faire du REST quand on ne peut pas envoyer des requêtes PUT et DELETE depuis le navigateur ?

Je connais que SOAP, mais le REST m'intèresse de plus en plus et apparament, cette techno est plutôt bien appréciée.

---

Certaines librairies indiquent la méthode dans un paramètre pour palier à l'incompatibilité de certains navigateurs qui ne gèrent pas les méthodes http PUT et DELETE notament. Pour faire court, tu ne devrais pas rencontrer de problèmes avec les navigateurs récents.

Pour les anglophiles:
http://stackoverflow.com/questions/1...t-web-browsers

Citation:

---

Envoyé par Farid63

Comment est-il possible de faire du REST quand on ne peut pas envoyer des requêtes PUT et DELETE depuis le navigateur ?

---

La solution est de passer le paramètre _method. Les frameworks tels que Ruby on Rails l'interprètent nativement.

Ex.
GET https://api.monservice.com/items/12?_method=DELETE
sera équivalent à
DELETE https://api.monservice.com/items/12

Du coup, ça passe bien.

J'ai fait un petit post sur mon blog à propos des services web RESTful.

je commence avec le webservice et l'architecture REST utilisant JAVA et Restlet me donne satisfaction quant à la multitude et la complétude : sécurité, représentation ...