SAVON - Quel est le point?

Question

Je veux dire, vraiment, qu'est-ce que le point de SAVON?

Les services Web ont été autour pendant un certain temps, et pendant un moment, il semblait que les termes de "SAVON" et "Web service" ont été largement interchangeables. Cependant SAVON semblait toujours difficile à manier et massivement trop compliqué pour moi.

Alors RESTE est venu, et tout à coup des services web.

Comme Joel Spolsky dit, donner un programmeur RESTE de l'URL, et ils peuvent commencer à jouer avec le service immédiatement, essayer de le comprendre.

Le SAVON est dissimulé derrière des fichiers wsdl et massivement détaillé XML, et en dépit d'être basée sur le web, vous ne pouvez pas faire quelque chose d'aussi simple que d'accéder à un service SOAP avec un navigateur web.

Donc, l'essence de ma question est:

• Sont-il de bonnes raisons de toujours choisir le SAVON sur le RESTE?
• Travaillez-vous avec du SAVON maintenant? Il serait mieux si l'interface a été de REPOS?
• Suis-je tort?

Answer 1

Comme Joel Spolsky dit, donner un programmeur RESTE de l'URL, et ils peuvent commencer à jouer avec le service immédiatement, essayer de le comprendre.

Alors que si le service avait bien spécifié, lisible à la machine du contrat, le programmeur ne pas avoir à perdre de temps à essayer de le comprendre.

(non pas que WSDL/SOAP est forcément un bon exemple de mise en place d'un contrat spécifié, mais c'était le point de WSDL)

À l'origine, SOAP est un protocole simple qui nous a permis d'ajouter un en-tête d'un message, et a normalisé la cartographie des instances de l'objet à des structures XML. Mettre la gestion des métadonnées dans le message simplifié le code client, vous pouvez très simplement persister et de la file d'attente de messages.

Je n'ai jamais besoin de l'en-tête de traitement des détails quand j'ai construit SAVON services en 2001. C'était avant WSDL, et il était alors normal d'utiliser GET pour obtenir des informations et des requêtes (pas différentes pour la plupart des applications qui prétendent être en RESTE, en RESTE est plus en termes de l'utilisation des liens hypertexte pour la découverte de services) et de POST avec un SAVON de charge utile pour effectuer des actions. Ces actions, qui ont créé des ressources serait de retour l'URL de la ressource créée pour le client, et le client peut alors accéder à la ressource. Je pense que c'est le fait que WSDL fait, il est facile de penser seulement en termes de RPC plutôt que les actions qui créent des ressources qui fabriquait du SAVON perdre de l'intrigue.

Answer 2

Le sujet est bien abordé dans Pourquoi est-savon considérés comme des épais.

Answer 3

En faisant quelques recherches pour comprendre certaines réponses ici (surtout John Saunders') j'ai trouvé ce post http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/

Le SAVON est plus fou que je ne le pensais...

Answer 4

La façon dont je le vois, le SAVON peut être plus "souple", mais comme un résultat, c'est juste trop compliqué (vous avez mentionné le WSDL, qui est toujours une pierre d'achoppement pour moi personnellement).

Je reçois de REPOS. C'est simple. Le seul bémol que je pourrais voir, c'est que vous limiter vous-même à ces 4 actions de base contre une seule ressource, ce qui peut ne pas correspondre exactement à la façon dont vous affichez vos données.

Answer 5

Le point de WSDL a été auto-découverte. L'idée était que vous ne pas avoir à écrire de code client, il serait auto-généré.

BTW. prochaine étape au-delà WSDL sont Sémantique des Services Web.