Pourquoi utiliser XML (SOAP) quand JSON est si simple et facile à manipuler?
recevoir et envoyer des données avec JSON se fait avec des requêtes HTTP simples. Alors que dans le savon, on doit s'occuper de beaucoup de choses. L'analyse XML est aussi parfois difficile. Même Facebook utilise JSON dans L'API Graph. Je me demande encore pourquoi on devrait toujours utiliser du savon? Y a-t-il une raison ou un domaine où le savon est encore une meilleure option? (Malgré le format de données)
aussi, dans les applications client-serveur simples (comme les applications mobiles connectés à un serveur), peut SOAP donner n'importe quel avantage sur JSON?
je serai très reconnaissant si quelqu'un peut enrôler les différences majeures/proéminentes entre JSON et SOAP considérant les informations que j'ai fournies(S'il y en a).
3 réponses
j'ai trouvé ce qui suit sur les avantages du savon
- Il ya une grande raison chacun colle avec du savon au lieu d'utiliser JSON. Avec chaque configuration de JSON, vous venez toujours avec votre propre structure des données pour chaque projet. Je ne veux pas dire comment les données sont codées et passé, mais comment le format formaté de données est défini, les données modèle.
- SOAP a une façon mûre de l'industrie de préciser que les données seront en le panier de forme est une collection de Produits et chaque produit peut avoir ces attributs, etc. Un document WSDL bien assemblé a vraiment cette cloué. C'est une spécification W3C.
- JSON a des façons similaires de spécifier cette structure de données. JavaScript la classe vient à l'esprit que la façon la plus courante de le faire. Un La classe JavaScript n'est pas vraiment une structure de données agnostique, bien établie,largement utilisée. Zut, JavaScript vraiment n'exécute que dans un seul environnement, le navigateur.
- en bref, SOAP a une façon de spécifier la structure des données dans un document formaté avec maturité (WSDL). JSON n'a pas de méthode standard pour faire ça.
si vous créez une application client et que l'implémentation de votre serveur est faite avec SOAP, vous devez utiliser SOAP côté client.
de nos jours le savon est une overkill complète, IMHO. C'était agréable de l'utiliser, agréable à l'apprendre, et c'est beau, nous pouvons utiliser JSON maintenant.
la seule différence entre les services SOAP et REST (peu importe si l'utilisation de JSON) est que SOAP WS a toujours son propre WSDL document qui pourrait être facilement transformé en une documentation auto-descriptive tandis que dans le repos vous devez écrire la documentation pour vous-même (au moins pour documenter les données structure.) Voici mes avantages et inconvénients pour les deux:
reste
Pros
- léger (en tous les moyens: aucune extension côté serveur ou côté client n'est nécessaire, aucun gros morceau de XML n'est nécessaire pour être transféré ici et là)
- libre choix du format de données - c'est à vous de décider si vous pouvez utiliser txt, JSON, XML, ou même créer votre propre format de données
- la plupart des les formats de données actuels (et même si utilisé XML) assure que seule la quantité vraiment nécessaire de données est transféré sur HTTP tandis que avec SOAP pour 5 octets de données, vous avez besoin de 1 Ko de XML junk (exagéré, ofc, mais vous avez le point)
Cons
- même s'il existe des outils qui pourraient générer la documentation à partir des commentaires de docblock, il est nécessaire d'écrire de tels commentaires de façon très descriptive si l'on veut obtenir une bonne documentation ainsi que
SAVON de marseille
Pros
- a une WSDL qui pourrait être générée à partir de commentaires docblock, même de base (dans de nombreuses langues, même sans eux) qui fonctionne bien comme une documentation
- même s'il y a des outils qui pourraient fonctionner avec WSDL pour donner une interface améliorée essayer cette demande (alors que je ne sais pas sur un tel outil pour le repos)
- structure de données stricte
Cons
- structure de données stricte
- utilise un XML (seulement!) pour les transferts de données alors que chaque requête contient beaucoup de camelote et la réponse contient cinq fois plus de camelote d'information
- le besoin de bibliothèques externes (pour le client et / ou le serveur, bien qu'il existe de nos jours de telles bibliothèques déjà une partie native de nombreuses langues, mais les gens ont toujours tendance à utiliser certains tiers)
pour conclure, Je ne vois pas de grande raison de préférer le savon au repos (et JSON). Les deux peuvent faire la même chose, il y a un support natif pour l'encodage et le décodage JSON dans presque tous les populaires web langage de programmation et avec JSON vous avez plus de liberté et les transferts HTTP sont nettoyés de beaucoup de camelote d'information inutile. Si Je si je construisais une API, J'utiliserais REST avec JSON.
je suis en désaccord un peu sur la tendance du JSON que je vois ici. Bien que JSON soit un ordre maginitude plus facile, j'oserais dire qu'il est assez limité. Par exemple, le savon WS n'est pas la dernière chose. En effet, entre le client/serveur soap vous avez maintenant le bus de services d'entreprise, le schéma d'authentification basé sur la cryptographie, la gestion des utilisateurs, les requêtes/réponses d'horodatage, etc. Pour tout cela, il y a quelques plates-formes logicielles énormes qui fournissent des services autour de SOAP (bien, "services web") et vont injecter des trucs dans votre XML. Donc, bien que JSON soit probablement suffisant pour les petits projets et un ordre de grandeur plus facile là-bas, je pense qu'il devient tout à fait limité si vous avez découplé le contrôle de la transmission et le contenu (c.-à-d. vous développez le contenu, le serveur réel, mais toute la transmission est gérée par une autre équipe, l'authentification par une autre équipe, le déploiement par une autre équipe). Je ne sais pas si mon expérience dans une grande entreprise est pertinente, mais je dirais que JSON ne survivra pas là-bas. Il y a trop d' contraintes en plus du besoin fondamental de représentation des données. Donc le problème n'est pas JSON RPC lui-même, le problème est qu'il manque les outils supplémentaires pour gérer la complexité qui se pose dans les applications complexes (pour ne pas dire que ce que vous faites n'est pas complexe, c'est juste que le logiciel reflète la complexité de l'entreprise qui le produit)