XML-RPC与REST的区别

Question

我即将在这里构建一个小型服务器，想要创建一个API。

我正在决定什么更好，并已经排除了SOAP，因为我认为那东西一团糟。现在我只剩下REST和XML-RPC。

我真的很喜欢XML-RPC，它非常容易实现，而且足够规范，所有客户端都可以轻松使用它。

最近，所有时髦的人都在做RESTful的事情，有时是使用JSON负载或XML文档，甚至是HTTP POST变量。

我认为那些人总是为每个服务重新发明轮子。我不明白为什么要使用REST而不是使用XML-RPC。

问题：

那么，有人能否提供使用REST+JSON实现API的实际原因，以便比起使用XML-RPC更好吗？

- Andre Garzia

---

通常当我们谈论“Web”时，REST风格通常是首选，因为它按照HTTP的方式工作...这里有一个在领英上关于这个主题的讨论。 - Adil

Answer 1

REST与RPC实现（例如XML-RPC）的区别是一种错误的二分法。您可以使用XML-RPC实现RESTful接口（尽管您可能不想这样做）。 话虽如此，有很多原因要使用纯HTTP以RESTful方式公开资源，而不是使用类似XML-RPC的技术自己编写RPC接口：

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

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

- Tyson

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中应限制响应大小。

- Ritchie

---

专利：简单来说，REST 的许多方面都有专利存在，因此仅基于专利费用选择似乎是投机性的。安全性：如果您使用 HTTP 进行传输，则可以在应用程序层读取标题/正文，因此我不确定您所说的不透明是什么意思。有效负载：这取决于服务的构建方式（因为调用不会按比例映射）以及您在任何一种情况下用于公开数据的格式，但您无法保证 RESTful 接口始终会“更轻量级”。 - Tyson

我同意专利、安全性和性能不是好的比较标准。关于性能，有JSON-RPC，它比XML-RPC更轻量级。 - Alan Evangelista