Quand SOAP est-il plus logique que REST?
D'après ma compréhension de REST, l'hypothèse implicite est que toutes les opérations sont des opérations CRUD. Parfois, vous ne faites pas d'opérations CRUD et faites une logique plus complexe. Dans ce cas, n'est-ce pas SOAP plus approprié? Ou est-il vrai que toutes les opérations, quelle que soit leur complexité, sont une série d'opérations CRUD, elles doivent donc être divisées en un ensemble d'opérations CRUD plus petites être appelé l'un après l'autre? Mais cela ne rend-il pas l'opération que vous essayez d'écrire plus compliquée? J'essaie de comprendre quand il pourrait être plus judicieux d'utiliser SOAP au lieu de REST .
Je vais commencer par ceci: je préfère de beaucoup REST à SOAP. REST a de grands avantages, si cela est fait correctement, comme la distributibilité, la mise en cache des réponses, une sémantique claire et définie, la possibilité d'être consommé directement dans un navigateur, et ainsi de suite. Cependant, j'aime argumenter contre moi-même, alors voici pourquoi vous devriez utiliser SOAP dans votre prochain projet. Beaucoup de ces points proviennent de REST en pratique que tout le monde devrait avoir sur son bureau lors du démarrage d'un projet REST-y .
Le savon est partout
Dans les années 00, SOAP a remplacé une tonne de technologies non interopérables comme CORBA, DCOM, RMI, pour n'en nommer que quelques-unes. S'il existe un système hérité que vous devez intégrer à ce millésime, il est probable qu'il parle SOAP et consommera avec plaisir votre WSDL. Chaque langage imaginable possède un outil qui analysera WSDL en objets de domaine, et de nombreux développeurs savent comment l'utiliser. Cela ne peut pas nécessairement être dit pour REST. Vous pourrait également subir la douleur d'interagir avec un service REST via une bibliothèque client HTTP directement (comme les composants HTTP d'Apache). La prise en charge des outils pour REST s'améliore: la dernière JAX-RS 2.0 a un client standard assez agréable à utiliser.
Le S dans SOAP signifie Simple
Voici la spécification pour SOAP 1.1 . Il est court et décrit très clairement à quoi ressemble un message SOAP. Une grande partie de la spécification est dédiée aux cas ésotériques de l'OMI (jamais en 10 ans, je n'ai jamais utilisé un tableau partiellement transmis, par exemple ), mais l'essentiel est: Enveloppe, En-tête, Corps. Je concède que l'en-tête et l'enveloppe sont redondants lorsque le message SOAP est envoyé via HTTP, mais SOAP peut être envoyé sur n'importe quel support (comme une autre réponse le mentionne), c'est donc un mal nécessaire. Vous pouvez facilement regarder un message SOAP, et vous n'avez pas besoin d'un logiciel sophistiqué pour écrivez-en un.
Les extensions WS- * ajoutent des fonctionnalités
Il n'y a pas de prise en charge intégrée des transactions dans les services Web REST. Il est possible de créer un service transactionnel REST, mais la sémantique de votre système transactionnel peut être différente de la sémantique de mon système transactionnel. SOAP a des extensions comme WS-Transactions qui définissent des workflows clairs et des mécanismes de cohérence transactionnelle. De même, d'autres extensions comme WS-Addressing et WS-Security décrivent le routage des messages et l'authentification/chiffrement des messages. Pour effectuer l'authentification des messages dans REST, vous devez soit utiliser SSL côté client, soit lancer le vôtre.
SOAP ne vous oblige pas à mapper les opérations de domaine sur CRUD
REST n'est pas tout sur CRUD, mais pour effectuer des opérations non-CRUD, vous devez les mapper sur les ressources. Ce n'est pas nécessairement une mauvaise chose ™, mais cela peut causer des maux de tête à vos concepteurs. Le mappage d'une opération verbale comme "extraire un livre" sur l'un des verbes HTTP pourrait être une demande de PATCH pour définir un indicateur isCheckedOut sur le book; il peut s'agir de la création d'une nouvelle ressource /checkout ou d'un certain nombre d'autres choses. Avec un service Web SOAPy et du code généré automatiquement à partir de WSDL, vous pouvez simplement faire service.checkOut(book, patron). L'intention est très claire.
Le mécanisme de défaillance de SOAP encourage une gestion des erreurs plus riche
OK, donc ce n'est pas parfait, et la plupart des services Web SOAP ne le font pas correctement, mais ce n'est pas la faute de SOAP. SOAP a un support intégré pour exceptions (défauts), qui sont des objets réels . Ils peuvent contenir de nombreux détails sur ce qui ne va pas et comment vous pouvez le corriger. REST utilise l'état HTTP codes est incroyablement pratique à cet égard, car il encourage le développeur à se demander s'il doit renvoyer un 400, 403, 500, etc. et ces codes ont des significations standard. Cependant, il n'y a pas de norme pour le corps du message, et il n'y a pas REST mécanisme pour forcer le service my-crappy-REST à renvoyer des réponses 200 OK Avec des corps d'erreur. C'est tout aussi facile pour un REST pour produire des réponses inutiles comme pour un service SOAP.
Mon expérience
Ce ne sont peut-être pas de bonnes raisons d'utiliser SOAP over REST dans votre prochain projet, mais je voulais en quelque sorte essayer de me convaincre.
Je suis actuellement sur un projet qui expose une API REST, et consomme une API SOAP, donc je suis dans le meilleur/le pire des deux) Je déteste les choses SOAP, mais c'est principalement parce que le système principal avec lequel je travaille laisse place à l'amélioration. JAX-RS est un serveur vraiment sympa REST API, et il est presque indolore. En raison de REST, et parce que nous sommes très stricts sur le respect du REST contraintes , nous utilisons beaucoup la mise en cache HTTP dans notre infrastructure, ce qui améliorera, espérons-le, notre expérience utilisateur. Nous ne sommes pas , cependant, faire un service HATEOAS complet parce que notre application ne l'exige tout simplement pas. Notre service est également principalement CRUD par sa nature, nous n'avons donc pas eu à prendre de décisions difficiles sur la façon de nom a verbe .
En bref, je suppose que SOAP n'est pas toujours un mauvais choix, mais il n'y a pas grand chose à faire sauf si vous avez déjà une grande infrastructure SOAP.
REST est construit autour de l'idée de faire des opérations CRUD sur des objets autonomes, ou dans le pire des cas, sur une hiérarchie d'objets étroitement couplée.
SOAP est moins structuré que cela, et est donc plus adapté aux transactions qui ont une structure plus fluide. SOAP les requêtes et les réponses ont une structure définie, dans la mesure où elles doivent se conformer à leur WSDL, mais cela laisse beaucoup de place pour les éléments facultatifs, les éléments répétitifs, les éléments complexes, etc.).
REST peut ressembler à CRUD, mais dans une architecture orientée ressources, vous pouvez gérer des cas complexes, même si cela peut nécessiter une certaine réflexion.
Par exemple, si vous souhaitez débiter une carte de crédit, cela peut sembler être un verbe et ne correspondrait donc pas à CRUD, mais il n'y a aucune raison pour laquelle vous ne pouvez pas disposer d'une ressource Purchase. Ensuite, pour un Purchase POST le service peut réellement débiter la carte de crédit dans les coulisses.
D'après ma compréhension de REST, l'hypothèse implicite est que toutes les opérations sont des opérations CRUD.
Certainement pas. Vous faites peut-être référence à une expérience d'un REST boîte à outils de service Web, mais en général il n'y a pas de restriction comme celle-ci. REST concerne l'échange de documents, de représentations d'État.
En fait, REST est si flexible que vous pouvez décrire toute votre logique complexe dans un document, POST en /transactions URL, et utilisez le /transactions/<id> pour surveiller l'exécution et récupérer les résultats. L'utilité d'une telle application de fusil de chasse de REST est une autre affaire et dépend de la conception de votre application.
La combinaison SOAP/WSDL peut être utilisée lorsqu'un contrat d'interface Web rigide est nécessaire, un cas qui peut être justifié dans certains scénarios d'entreprise. SOAP peut être utilisé avec REST, mais la combinaison SOAP/REST n'a pas trouvé ses partisans, probablement parce qu'elle n'ajoute rien de valeur aux architectures courantes REST. I personnellement, j'utilise SOAP, quand je le fais, uniquement pour des raisons de compatibilité/héritage ou dans le cadre de toute la gamme WS- * lorsque je faisais du grid computing.
En plus des excellentes réponses déjà ici, une autre raison pourrait être avec qui vous communiquez ou dans quelle langue vous développez.
Certaines applications n'ont que des interfaces SOAP ou REST. Dans d'autres cas, les langages de programmation privilégient (par leur conception ou simplement leur pratique) un protocole par rapport à l'autre).
Par exemple. Ruby on Rails a un excellent support pour REST et si vous avez besoin d'aide beaucoup de ressources. En revanche, il existe des modules pour faire SOAP dans Rails, mais ils ne sont pas aussi bien pris en charge et vous pouvez avoir beaucoup plus de difficulté avec cela. De plus, la culture de Rails consiste à utiliser REST et si votre application ne prend pas en charge cela, vous ne pourrez pas forcer Rails développeurs à l'utiliser ou ils s'en plaindront fortement).
D'un autre côté, Microsoft a été un grand partisan de SOAP et même si je ne suis pas un programmeur C # ou .NET, je crois comprendre que la prise en charge de SOAP = il y en a très bien. Il en va de même pour Java, il semble y avoir un meilleur support pour SOAP que pour REST là-bas).
Cela dit, aucun des exemples ci-dessus n'est impossible avec l'un ou l'autre, juste que la culture des programmeurs qui utilisent le langage ou le langage lui-même a tendance à favoriser l'un ou l'autre. Vous devez en tenir compte lorsque vous prenez votre décision.
Lorsque vous prévoyez uniquement d'interagir avec la pile Microsoft et que la consommation de bande passante à grande échelle n'est pas un problème, SOAP est mieux.
Sinon, offrir une API uniquement SOAP à des non-Microsofters est généralement considéré comme impoli, et je pense qu'il doit y avoir un état dictatorial, quelque part, où cela vous vaut la peine de mort.
Le savon a plus de sens que de repos lorsque vous savez que vous vous en tiendrez à .net et que vos consommateurs resteront à .NET.
Je dis cela, car avec SOAP et l'intégration de Visual Studio, la connexion est un jeu d'enfant.
Sortez de l'arène .NET et vous connecter à un service de repos est une question simple pour toute autre langue.
Si vous devez utiliser .NET en tant que fournisseur et que vous souhaitez fournir une interface reste comme pour vos consommateurs, optez pour ASP.NET MVC, sinon, optez pour WebAPI. (MVC permet des comportements complexes similaires à SOAP, assurez-vous simplement de documenter clairement vos entrées et sorties)
SOAP vous offre un contrat bien défini (WSDL) facilement accessible à vos clients. Avec la bonne technologie, il est très facile de générer des API natives pour votre service.
Ce contrat est également utile pour les clients pour créer de fausses implémentations du service à des fins de test.
> When does SOAP make more sense than REST?
Avec soap, vous avez d'autres normes d'interopérabilité WS - * qui couvrent entre autres XML_Signature et XML_Encryption
En théorie SOAP n'est pas limité à http (s) il peut également être utilisé via ftp, email, .... Cependant je n'ai jamais vu SOAP avec non http (s).
Si je peux choisir entre du savon et du repos, je préférerai toujours le repos.
D'après ce que je me souviens avoir lu dans un livre.
1) SOAP impose une structure
2) L'utilisation de Soap est plus sûre
3) Il peut gérer des structures complexes, par exemple passer des objets.
Je pense que REST serait une meilleure solution si vous avez de petites applications. Android a utilisé Rest et non soap, je suppose parce qu'il est plus léger.