REST 与 RPC - *实际用途* 差异

Question

当 REST 已经流行时，我开始编写 Web 应用程序和分布式应用程序，所以我实际上从未使用过 RPC。

在搜索它们之间区别的简单解释时，我开始理解，但一些例子让我感到困惑。
我看到了这样的事情：

GET /getLastUser

或者这个：

POST /changeUserName

如果 REST 用于资源，而 RPC 用于过程，那么将 RPC 用于此类事情不是一种不好的做法吗？

如果我错了，请纠正我，但在我看来，RPC 应该更纯粹是功能性的。
这意味着调用过程应该始终：

• 对相同的参数返回相同的结果
• 不影响状态

所以，RPC 调用是这样的：

GET /addTwo?num=5

返回如下内容：

{
    "result": 7
}

对我来说似乎更合乎逻辑（尽管这是一个非常简单的例子）。

如果这个问题因为过于“基于意见”而被关闭，我就会知道我应该做任何我想做的事......

Answer 1

RPC 并非旨在发挥作用。两次调用相同的过程并不能保证结果。

这个问题可以用几种不同的方式来回答，而且非常深刻。我认为这可能是一个公平的总结。

• 对于 RPC，原语通常是函数名称、参数和结果。
• 对于 REST，原语是一种“资源表示”。

因此，在 RPC 中，您可能会调用函数，而在 REST 中，您实际上是在发送和检索资源的状态，而与协议无关。

这意味着您通常只询问服务器“您能告诉我此资源的状态吗”，或者您告诉服务器“这是一个新的资源状态，请将其存储在此位置”。 REST 将给出的唯一成功答案是“当前状态”或“此操作有效”，但对于 RPC，问题（函数 + 参数）和答案（结果）可以是任何东西。

所以你可以争辩说，当你这样描述它时，RPC 要灵活得多。可能是这样，但由于 REST 将自身限制为仅传输状态，因此您可以获得很多基于 RPC 的简单协议所无法提供的保证。

REST 不仅仅是传输状态。使用超链接是服务被称为 REST 的另一个重要要求，这也是 RPC 无法“开箱即用”的东西。

最后，可以说 HTTP 本身是一个类似 RPC 的协议。我认为可以在任何 RPC 服务之上构建一个 RESTful 服务。