Quel est l'avantage de XML-RPC par rapport au XML simple?

la réponse courte est: les deux protocoles peuvent être utilisés pour faire des appels de procédure à distance (RPC). Les deux protocoles exigent la définition d'un schéma au niveau de l'application et, d'une manière générale, aucun des deux protocoles n'exige de schéma supplémentaire pour définir la façon de sérialiser les objets au niveau de la langue (voir ci-dessous pour plus de détails).

cependant, XmlRpc bénéficie d'un plus grand soutien de la part des bibliothèques qui utilisent des fonctionnalités de méta-programmation (réflexion) du langage pour cartographier les appels XmlRpc, directement (Eh bien, jamais 100% directement) au niveau de la langue appels de fonction. La raison pour laquelle il y a un meilleur support pour XMLRPC que le XML simple est (a) un accident/résultat historique de marketing de la part des promoteurs de XmlRpc, ou (b) la somme des problèmes mineurs de traduction énumérés ci-dessous fait pencher la balance en faveur de XmlRpc.

d'un autre côté, XmlRpc souffre de 2 inconvénients principaux: (1) Il nécessite environ 4 fois plus de bande passante, et (2) Il subvertit l'intention du schéma XML-validation outils: chaque paquet sera simplement estampillé comme "oui, c'est valable XmlRpc", indépendamment de fautes d'orthographe et d'omissions dans l'application-niveau de champs.

La réponse longue:

contrairement à la croyance populaire, vous n'avez pas besoin d'une norme pour définir comment encoder des objets de niveau de langage en XML simple - il n'y a généralement qu'une seule façon "raisonnable" (à condition que le schéma du niveau de l'application définisse si vous utilisez des attributs XML ou non), par exemple:

class Room {
    int id=1;
    String code="MR-101";
    String name="Maths room";
    int capacity=30;
};

codé comme:

<Room>
    <id>1</id>
    <code>MR-101</code>
    <name>Maths room</name>
    <capacity>30</capacity>
</Room>

XmlRpc a été spécialement conçu pour faciliter la création de bibliothèques qui sérialisent/désérialisent automatiquement les objets au niveau de la langue dans les appels RPC, et en tant que tel, il a quelques avantages mineurs lorsqu'il est utilisé de cette façon:

1. avec XML simple, il est possible qu'une structure avec un seul membre soit confondue avec un tableau avec un seul élément.

2. xmlrpc définit un format Heure/date standard. {Bien que le traitement des horodateurs et des horodateurs purs ou purs sont définis au niveau de l'application.}

3. XmlRpc vous permet de passer des arguments à la fonction sans les nommer; les appels RPC XML simples exigent que vous nommiez chaque argument.

4. XmlRpc définit une méthode standard pour nommer la méthode appelée: "methodName". Avec le XML simple, la balise du noeud racine serait généralement utilisé à cette fin, bien que les alternatives sont possible.

5. XmlRpc définit un système de type simple: entiers, chaînes, et ainsi de suite. {Notez qu'avec les langages statiquement typés, les types doivent être compilés dans l'objet destination de toute façon, et sont donc connus, et avec les langages dynamiquement typés, souvent int's et float's et les chaînes peuvent être utilisés de façon interchangeable; notez également que le système de type XmlRpc serait typiquement une mauvaise correspondance pour le système de type de la langue de destination qui peut avoir plusieurs integer types, et ainsi de suite.}

7. il existe une" perception de marketing "selon laquelle XML décrit les" documents", alors que XmlRpc est conçu pour les appels de procédure. Le la perception est que l'envoi d'un message XmlRpc contient une obligation pour le serveur d'effectuer une certaine action, alors que cette perception n'est pas aussi forte avec du XML simple.

certains diront "qui s'en soucie - l'analyse des données XML à l'aide de descente récursive/DOM/SAX est assez facile de toute façon", auquel cas la plupart des objections ci-dessus ne sont pas pertinentes.

pour ceux qui préfèrent encore la facilité d'utilisation d'obtenir des objets de langue maternelle créés automatiquement, de nombreuses langues principales ont des bibliothèques qui sérialisent automatiquement les objets au niveau de la langue en XML sans recourir à XmlRpc, par exemple:

.NET - Java - Python

il se peut que le succès de XmlRpc, tel qu'il est, découle de la disponibilité des bibliothèques qui créent automatiquement des objets au niveau du langage, et à leur tour ces bibliothèques ont un avantage sur leurs homologues XML simples en raison de la la liste de questions ci-dessus.

• la prise en charge du XML simple est omniprésente et ne nécessite généralement pas d'intégration avec les bibliothèques de tiers de grande taille. De nombreuses applications nécessitent de toute façon une conversion des objets créés automatiquement en objets propres à l'application.

• de nombreuses implémentations xmlrpc ne produisent pas les vrais objets au niveau du langage des programmeurs de tri s'attendraient et au lieu de cela exigeraient par exemple des recherches de champs ou une syntaxe supplémentaire.

• si un document de définition de schéma est utilisé pour valider les appels RPC, tel qu'un fichier DTD, alors vous perdez la possibilité de vérifier le schéma au niveau de l'application-le fichier DTD vous dira simplement que "ceci est valide XmlRpc". Il n'y a pas, à ma connaissance, de manière standard pour définir un schéma au niveau de l'application avec un xmlrpc basé protocole.