XML-RPC vs 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 vs RPC实现像XML-RPC是错误的二分法。你可以使用XML-RPC实现一个RESTful接口（尽管你可能不想）。这就是说，有一堆的理由，你为什么会想用香草HTTP，而不是滚动使用技术，如XML-RPC自己的RPC接口公开资源的REST方式：

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

查看this博客文章了解更多信息。

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中。

• ，使得可以呈现为返回值，其中可以简单地进行REST客户端来处理流，因为它到达该XML-RPC客户端必须加载整个响应到内存中。这意味着对于REST调用来说，响应XML-RPC API应限制响应大小的任何数量的记录都可以。