当REST已经流行时，我开始编写Web应用程序和分布式应用程序，所以我实际上从未使用过RPC。
在寻找他们之间差异的简单解释时，我开始理解，但有些例子让我感到困惑 我看到了这样的事情：
GET /getLastUser
或者这个：
POST /changeUserName
如果REST是针对资源的，而RPC是针对程序的，那么使用RPC来做这样的事情不是一个坏习惯吗？
如果我错了，请纠正我，但就我看来， RPC应该更加纯粹。
这意味着调用过程应始终：
所以，RPC调用如下：
GET /addTwo?num=5
返回这样的内容：
{
"result": 7
}
对我来说似乎更合乎逻辑（虽然这是一个非常简单的例子）。
如果这个问题因为过于“基于意见”而被关闭，我只会知道我应该做任何我想要的事情......
答案 0 :(得分：2)
RPC并不意味着功能。两次调用相同的过程不能保证结果。
这个问题可以用几种不同的方式回答，而且非常深刻。我认为这可能是一个公平的总结。
所以使用RPC你可以调用一个函数，在RPC中你实际上是在发送和检索资源的状态，而不管协议如何。
这意味着您通常只询问服务器＆＃39;您能否告诉我该资源的状态，或者您告诉服务器这里是一个新的资源状态，请将其存储在这个位置＆＃39;。 REST将给出的唯一成功答案是＆＃34;当前状态＆＃34;或者＆＃34;这个操作起作用了＃34;但是对于RPC，问题（函数+参数）和答案（结果）可以是任何东西。
所以你可以争辩说，当你这样描述时，RPC更灵活。它可能是，但由于REST仅限于传输状态，因此您可以获得很多基于RPC的协议不能提供的保证。
REST不只是关于转移状态。使用超级链接是服务被称为REST的另一个重要要求，这也是你不会开箱即用的东西。用RPC。
最后，可以说HTTP本身就是类似RPC的协议。我认为可以在任何RPC服务之上构建RESTful服务。