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 中，您实际上是在发送和检索资源的状态，而不管协议(protocol)如何。

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

所以你可以争辩说，当你这样描述它时，RPC 更加灵活。可能是这样，但是因为 REST 仅限于传输状态，所以您获得了许多基于简单 RPC 的协议(protocol)无法提供的保证。

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

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