Différence entre XML sur HTTP et SOAP sur HTTP
SOAP over HTTP est-il un sous-ensemble de XML over HTTP puisque je suppose SOAP aussi un xml qui confirme à un schéma (schéma SOAP)? Je suppose XML sur HTTP service est accessible via GET ou POST. Est-ce que SOAP sur HTTP utilise toujours POST? En cas de XML sur HTTP Je suppose que l'inconvénient est que le fichier de schéma doit être partagé avec tous les consommateurs alors qu'en cas de SOAP sur HTTP, ce sera un seul fichier WSDL. Serait-il possible d'aider me faire connaître la différence et aussi l'avantage de l'un sur l'autre?
SOAP est une spécialisation de XML, car il a un schéma, tel que http://www.xmlsoap.org/soap/envelope/ , tandis que XML est plus général.
Pour utiliser GET, vous pouvez lire cette discussion: http://www.coderanch.com/t/463869/Web-Services/Java/SOAP-request-HTTP , mais essentiellement SOAP se fait via POST, bien qu'Axis2 semble avoir un support pour GET, comme un moyen de faire fonctionner SOAP dans un monde où REST semble régner.
Et, selon cet article IBM ( http://www.ibm.com/developerworks/xml/library/x-tipgetr/index.html ) SOAP 1.2 présente GET.
Comme vous l'avez mentionné, SOAP est un standard, il existe donc des outils qui peuvent facilement fonctionner avec, y compris la génération de client dynamique, comme indiqué dans cette question, client de service Web de proxy dynamique soap en java? , où le client génère-t-il les talons nécessaires lors de la connexion?.
Si vous utilisez XML sur http, il peut être préférable, selon les besoins, de transférer des données, mais dans les cas d'utilisation, je pense qu'il semblerait préférable d'utiliser simplement JSON et REST, mais si vous le souhaitez transférer XML, ou envoyer XML, alors vous pouvez regarder à l'aide de REST.
POST serait la meilleure option, car GET a des limitations de taille ( longueur maximale de la requête HTTP GET? ), c'est probablement pourquoi SOAP est presque toujours POST.
Le WSDL n'est pas nécessairement un seul fichier, dans WCF, si je me souviens bien, il existe de nombreux fichiers xml qui doivent être rassemblés pour que le WSDL soit complet.
L'avantage dépend de votre cas d'utilisation, mais je trouve que l'utilisation de REST et permettre à l'utilisateur de sélectionner le type est utile car il peut être trivial de basculer entre JSON et XML, par exemple, et est le meilleur choix pour XML sur HTTP.
SOAP est le meilleur lors de l'intégration avec des technologies plus anciennes car c'est peut-être tout ce qu'ils peuvent facilement utiliser. Par exemple, lorsque j'ai créé des services Web pour l'intégration SAP, il peut être plus difficile de ne pas utiliser SOAP, selon la capacité du programmeur ABAP.
Vous pouvez trouver cette question d'utilisation:
Comment SOAP et REST fonctionne avec la réponse XML/JSON?
et pour une discussion sur JSON et XML dans les services Web, vous pouvez trouver ceci utile:
http://digitalbazaar.com/2010/11/22/json-vs-xml/
J'ai oublié ce lien, car ils font une brève comparaison, mais au final, vous pouvez facilement prendre en charge les deux. Dans WCF, j'avais un contrôleur qui avait la logique métier et devait contenir des fichiers .aspx, un pour SOAP et un pour REST, et certains services Web prenaient en charge les deux, car il s'agissait simplement de gérer les différences de demande et de réponse. Donc, si vous voulez fournir un support pour les deux, et avoir une analyse de rentabilisation montrant que cela a du sens, choisissez un cadre qui le rendra facile à faire.
http://digitalbazaar.com/2010/11/22/json-vs-xml/
Fondamentalement, l'objectif est de fournir des services aux clients via le Web. Quels clients vont se connecter? Comment les clients trouveront-ils le plus facile de les contacter? Combien de données sont transmises dans la demande?
Ces types de questions mèneront à la meilleure solution pour vos besoins.