xml - 与纯XML相比，XML-RPC有什么好处？

Question

我的公司使用XML-RPC已经有一段时间了，但最近我想知道xml-rpc与普通xml相比有什么好处。首先，这是可怕的“肥胖”，考虑一下：

<struct>
    <member>
        <name>ROOM_ID</name>
        <value>
            <int>1</int>
        </value>
    </member>

    <member>
        <name>CODE</name>
        <value>
            <string>MR-101</string>
        </value>
    </member>

    <member>
        <name>NAME</name>
        <value>
            <string>Math Room</string>
        </value>
    </member>

    <member>
        <name>CAPACITY</name>
        <value>
            <int>30</int>
        </value>
    </member>
</struct>

相比之下：

<room><ROOM_ID>1</ROOM_ID><CODE>MR-101</CODE>
<NAME>Math Room</NAME><CAPACITY>30</CAPACITY></room>

甚至这个：

<room ROOM_ID=1 CODE=MR-101 NAME=”Math Room” CAPACITY=30 />

其次，XML- RPC似乎相当普遍，但并不十分普遍，我对C++和PHP的支持也不那么感兴趣。我试过的所有两种语言的库都有问题。
第三，在我看来，使用纯XML进行远程过程调用和使用XML-RPC一样容易。{（9/9/2009）：每种语言都有将语言级对象序列化为XML的库。XML和XML-RPC都要求定义应用程序级架构，例如字段的拼写，但都不需要定义任何其他架构。许多人使用纯xml进行rpc调用。}
那么XML-RPC的附加值是什么？

Answer 1

简而言之，这两个协议都可以用来进行远程过程调用（rpc）。这两个协议都需要定义一个应用程序级模式，一般来说，这两个协议都不需要任何额外的模式来定义如何序列化语言级对象（参见下面的部分详细信息）。
然而，xmlrpc从使用语言的元编程（反射）特性来映射xmlrpc调用的库获得了更大的支持，直接（好吧，永远不要100%直接）映射到语言级函数调用。对xmlrpc的支持比普通的xml更好的原因是（a）xmlrpc支持者的市场营销的历史事故/结果，或者（b）下面列出的小翻译问题的总和使支持xmlrpc的天平倾斜。
另一方面，xmlrpc有两个主要缺点：（1）它需要大约4倍的带宽，（2）它颠覆了xml schema验证工具的意图：每个包都将被简单地标记为“是，这是有效的xmlrpc”，而不管应用程序级字段。
答案很长：
与普遍的看法相反，您不需要一个标准来定义如何用纯XML编码语言级对象-通常只有一种“合理的”方法（前提是应用程序级模式定义您是否使用XML属性），例如：

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

编码为：

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

xmlrpc是专门为方便在rpc调用中自动序列化/取消序列化语言级对象的库的创建而设计的，因此，当以这种方式使用时，它有一些次要的优点：
对于纯XML，具有单个成员的结构可能与具有单个元素的数组混淆。
xmlrpc定义标准时间/日期格式。{虽然时区和纯时间或纯日期时间戳的处理是在应用程序级别定义的。}
xml rpc允许您向函数传递参数而不命名它们；普通的xml-rpc调用要求您命名每个参数。
xmlrpc定义了一种标准的方法来命名被调用的方法：“method name”。对于纯XML，根节点的标记通常用于此目的，尽管可以选择其他标记。
xmlrpc定义了一个简单的类型系统：整数、字符串等。{注意，对于静态类型的语言，类型无论如何都必须编译到目标对象中，因此是已知的；对于动态类型的语言，通常int、float和string可以互换使用；还要注意，xmlrpc类型系统通常与目标语言的类型系统不匹配，目标语言的类型系统可能有多个整数类型，依此类推。}
xmlrpc库通常直接与http库集成，而xml序列化库都是（？）要求应用程序程序员将xml文本传递给http调用。在更现代的语言中，比如java/python/c，这是一件小事，但对于c++来说不是。
有一种“营销观念”认为XML描述了“文档”，而xmlrpc是为过程调用而设计的。感觉是发送xmlrpc消息包含服务器执行某些操作的义务，而对于纯xml，这种感觉没有那么强烈。
有些人会说“谁在乎-无论如何，使用递归下降/dom/sax解析xml数据是非常容易的”，在这种情况下，上述大多数反对意见都是无关紧要的。
对于那些仍然喜欢易于使用的自动创建本机语言对象的人来说，许多主要语言都有一些库，这些库可以自动地将语言级对象序列化为xml，而无需借助xmlrpc，例如：
.NET
Java
Python
xmlrpc的成功，可能源于自动创建语言级对象的库的可用性，而这些库又由于上面列出的问题而比普通的xml库具有优势。
xmlrpc的缺点是：
正如在问题中提到的，它是可怕的肥胖
对纯xml的支持无处不在，通常不需要与大型第三方库集成。许多应用程序无论如何都需要将自动创建的对象转换为应用程序自己的对象。
许多xmlrpc实现无法生成程序员所期望的真正语言级对象，而是需要运行时查找字段或额外语法。
如果使用架构定义文档来验证rpc调用，例如dtd文件，那么您将无法检查应用程序级架构-dtd文件只会告诉您“这是有效的xmlrpc”。据我所知，没有任何标准方法可以使用基于xmlrpc的协议定义应用程序级架构。