XML-RPC比普通XML有什么好处？

我的公司已经使用了 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-RPC轻松地进行简单的XML的远程过程调用。 {(9/9/2009)：每个语言都有用于将语言级对象序列化为XML的库。 XML和XML-RPC需要定义应用程序级别的模式，例如，字段应如何拼写，但是也不需要任何额外的模式来定义。许多人用纯XML进行RPC调用。}

那么XML-RPC的增值是什么？

简短的答案是：两种协议都可用于进行远程过程调用(RPC)。两种协议都需要定义一个应用级模式，一般而言，两种协议都不需要任何额外的模式来定义如何对语言级对象进行序列化(有关详细信息，请参见下文)。

然而，XmlRpc从使用元编程(反射)语言功能的库获得更大的支持，可将XmlRpc调用直接映射到语言级别函数调用(而不是直接100％)。 XmlRpc比普通XML更好的支持的原因是(a)XmlRpc支持者的一个历史事故/营销结果，或者(b)下面列出的小翻译问题的总和提示了有利于XMLRPC。

另一方面，XmlRpc有两个主要缺点：(1)它需要大约4倍的带宽，(2)它破坏了XML模式验证工具的意图：每个数据包将被简单地标记为“是的，这是有效的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定义了一个标准的时间/日期格式。 {虽然在应用层面定义了时区和纯时间或纯日期时间戳的处理。
> XmlRpc可以让参数传递给函数而不必命名它们;纯XML RPC调用需要为每个参数命名。
> XmlRpc定义了一个标准方法来命名被调用的方法：“methodName”。使用普通XML，根节点的标签通常用于此目的，尽管替代方案是可能的。
> XmlRpc定义一个简单的类型系统：整数，字符串等等。 {注意，使用静态类型语言，类型必须被编译到目标对象中，因此是已知的，并且使用动态类型语言，通常int和float和字符串可以互换使用;还要注意，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的协议来定义应用程序级架构是没有任何标准的方法。

XML-RPC比普通XML有什么好处？

相关文章