XML-RPC与REST

Question

这是一个更具理论意义的问题。我将在这里构建一个小服务器，并想为它创建一个API。我正在决定什么是更好的，并且已经排除了SOAP，因为在我看来那个东西是一团糟。剩下的就是REST和XML-RPC。我真的很喜欢XML-RPC，它实现起来真的很简单，而且很规范，所有的客户都可以很容易地使用它。如今，所有很酷的孩子都在做RESTful的事情，有时是使用JSON有效负载或XML文档，甚至是HTTP POST变量。我认为这些家伙总是为每个服务重新发明轮子。我看不出使用REST比使用XML-RPC有什么好处。

那么，这里有人能提供使用REST+JSON实现应用编程接口而不是仅仅使用XML-RPC的实际原因吗？

Answer 1

像XML-RPC这样的REST和RPC实现是错误的二分法。您可以使用XML-RPC实现一个RESTful接口(尽管您可能不想这样做)。也就是说，您希望使用vanilla HTTP以RESTful方式公开资源，而不是使用XML- RPC这样的技术滚动您自己的RPC接口，原因有很多：

1. 将来的操作主要由服务器控制，而不是通过过程调用在客户端中进行硬编码，从而简化了部署，并且可以开箱即用地使用缓存、节流和版本控制等versioning.
2. Existing实现。
3. 您使用
4. 接口执行的自定义过程的范围可能太窄。

有关更多信息，请参阅this博客。

Answer 2

• XML-RPC受到专利保护。你可能会发现有一天你被要求为它的使用支付版税。据我所知，REST并非如此。
• XML-RPC请求对于安全基础设施是不透明的。而支持超文本传输协议的防火墙可以配置为允许REST调用读取数据，但不允许更新或删除数据。

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

• REST是轻量级的(特别是在使用

而不是

• 的时候)。所有XML-RPC调用都是HTTP POST。这有很多含义。包括那个

- REST requests benefit from HTTP cacheing infrastructure where all XML-RPC calls must be processed by the target server.
- REST enables the client to check for updates using a simple HTTP HEAD request. To do the same in XML-RPC, you would need to build it into your API.

​

XML-

• 客户端必须将整个响应加载到内存中，这样才能以返回值的形式出现，这样REST客户端就可以简单地在流到达时对其进行处理。这意味着REST调用可以响应任意数量的记录，而XML-RPC应该限制响应的大小。