XML-RPC与REST

Question

这是一个更理论化的问题.我即将在这里构建一个小服务器,并希望为它创建一个API.我决定什么是更好的,已经排除了SOAP,因为我认为这件事情很糟糕.我留下了REST和XML-RPC.我非常喜欢XML-RPC,它实现起来非常简单,并且它足够常规,所有客户端都可以轻松使用它.现在所有很酷的孩子都在做RESTful的东西,有时候使用JSON有效载荷或XML文档,甚至是HTTP POST VARIABLES.我认为这些人总是为每项服务重新发明轮子.我没有看到通过REST使用XML-RPC可以获得什么.

那么,这里有人可以提供使用REST + JSON而不仅仅使用XML-RPC实现API的实际原因吗？

Answer 1

REST与RPC实现(如XML-RPC)是一种错误的二分法.您可以使用XML-RPC实现RESTful接口(尽管您可能不希望这样).也就是说,有很多原因导致您希望使用vanilla HTTP以RESTful方式公开资源,而不是使用XML-RPC之类的技术来滚动您自己的RPC接口:

1. 未来的操作主要由服务器控制,而不是通过过程调用在客户端中进行硬编码,从而简化部署和版本控制.
2. 可以直接使用缓存,限制和版本控制等现有实现.
3. 使用RPC接口滚动的自定义过程可能过于狭窄.

有关详细信息,请参阅此博客文章.

Answer 2

• XML-RPC受到专利保护.您可能会发现有一天您被要求支付使用费.据我所知,REST不是.

• XML-RPC请求对安全基础结构不透明.而HTTP感知防火墙可以配置为允许REST调用读取数据但不更新或删除它.

REST的其他优点更适用于处理大型数据集.

• REST在线上更轻(特别是在使用JSON而不是XML时).

• XML-RPC忽略HTTP语义.所有XML-RPC调用都是HTTP POST.这有很多含义.包括那个

  • REST请求受益于HTTP缓存基础结构,其中所有XML-RPC调用必须由目标服务器处理.
  • REST使客户端能够使用简单的HTTP HEAD请求检查更新.要在XML-RPC中执行相同操作,您需要将其构建到API中.

• XML-RPC客户端必须将整个响应加载到内存中,以便可以将其显示为返回值,以便REST客户端在流到达时处理流.这意味着REST调用可以响应任意数量的记录,其中XML-RPC API应该限制响应的大小.