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

我的公司已经使用XML-RPC一段时间了,但最近我想知道XML-RPC与普通XML相比有什么好处.首先,它是可怕的"肥胖",考虑:

    
        ROOM_ID
        
            1
        
    

    
        CODE
        
            MR-101
        
    

    
        NAME
        
            Math Room
        
    

    
        CAPACITY
        
            30
        
    

与此相比:

1MR-101
Math Room30

甚至这个:

其次,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;
};

编码为:

    1
    MR-101
    Maths room
    30

XmlRpc专门设计用于促进库的创建,这些库在RPC调用中自动序列化/反序列化语言级对象,因此当以这种方式使用时它具有一些小的优点:

使用纯XML,具有单个成员的结构可能与具有单个元素的数组混淆.

XmlRpc定义标准时间/日期格式.{尽管在应用程序级别定义了时区和纯时间或纯日期时间戳的处理.}

XmlRpc允许您在不命名的情况下将参数传递给函数; 纯XML RPC调用要求您为每个参数命名.

XmlRpc定义了一种标准方法来命名被调用的方法:"methodName".使用Plain 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的协议定义应用程序级模式的任何标准方法.

主要优点是有人已经为您制定了调用架构.这在具有反射的语言中特别有用,你可以盲目地将一个复杂的结构传递给RPC调用,它将解决如何将它转换为XML的问题.它在C++中的价值较低,你必须告诉XML-RPC库所有数据类型都是明确的.

你是对的,它没有风靡世界.你在图书馆找到的奇怪之处是由于这种低水平的兴趣.我自己用了两个,发现两个都有错误.两者都是放弃软件,所以我无处可以发送补丁,因此我有两个版本的私有补丁版本.叹.