22

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

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

4

2 回答 2

20

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

  1. 未来的操作主要由服务器控制，而不是通过过程调用在客户端中硬编码，从而简化了部署和版本控制。
  2. 可以开箱即用地使用缓存、限制和版本控制等现有实现。
  3. 使用 RPC 接口滚动的自定义过程可能范围太窄。

有关更多信息，请参阅此博客文章。

于 2012-12-06T01:06:42.943 回答
10

  • 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 应该限制响应的大小。

于 2012-11-28T02:48:51.670 回答