XML-RPC 与 REST

Question

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

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

Answer 1

REST 与 RPC 实现（如 XML-RPC）是错误的二分法。您可以使用 XML-RPC 实现 RESTful 接口（尽管您可能不想这样做）。也就是说，有很多原因让您希望使用普通 HTTP 以 RESTful 方式公开资源，而不是使用 XML-RPC 之类的技术滚动您自己的 RPC 接口：

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

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