XML-RPC与REST

Question

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

有关详细信息，请参阅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应该限制响应的大小。