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 服务。