REST和RPC之间的Web服务差异

您不能仅仅通过查看您发布的内容来明确区分REST或RPC。

REST的一个约束是它必须是无状态的。如果你有一个会话，那么你就有一个状态，所以你不能把你的服务称为RESTful的。

事实上，你在你的URL中有一个动作(即getAllData)是对RPC的指示。在REST中，您交换表示，您执行的操作由HTTP谓词指定。同样，在REST中，内容协商不是使用?p={JSON}参数执行的。

不知道您的服务是否是RPC，但它不是RESTful的。你可以在网上了解其中的区别，这里有一篇文章让你开始:揭穿RPC的神话休息。您更了解服务内部的内容，因此将其函数与RPC进行比较，并得出自己的结论。

REST最好被描述为与资源一起工作，而RPC更多地是关于操作。

< >强休息 代表具象状态传输。这是一种组织独立系统之间交互的简单方法。 RESTful应用程序通常使用HTTP请求来发布数据(创建和/或更新)、读取数据(例如，进行查询)和删除数据。因此，REST可以使用HTTP来完成所有四个CRUD(创建/读取/更新/删除)操作

< >强RPC 主要用于跨不同模块通信，以服务用户请求。 例如，在openstack中，nova、glance和neutron在启动虚拟机时是如何协同工作的

考虑下面的HTTP api示例，该示例模拟餐厅中的订单。

• RPC API从“动词”的角度考虑，将餐厅功能暴露为接受参数的函数调用，并通过似乎最合适的HTTP动词调用这些函数——用于查询的“get”等等，但动词的名称纯粹是附带的，对实际功能没有真正的影响，因为你每次都调用不同的URL。返回码是手工编码的，是服务契约的一部分。
• 相比之下，REST API将问题域内的各种实体建模为资源，并使用HTTP动词来表示针对这些资源的事务——POST用于创建，PUT用于更新，GET用于读取。所有这些动词，都在同一个URL上调用，提供不同的功能。常用的HTTP返回码用于传递请求的状态。

下单:

• RPC: http://MyRestaurant:8080/Orders/PlaceOrder (POST: {Tacos对象})
• http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (POST: {Tacos对象})

检索订单:

• Rpc: __abc0 (get)
• Rest: __abc0 (get)

更新订单:

• RPC: http://MyRestaurant:8080/Orders/UpdateOrder (PUT:{菠萝Tacos对象})
• REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (PUT:{菠萝Tacos对象})

示例取自sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

因此，我认为:

我的实体是否持有/拥有数据?然后RPC:这是我的一些数据的副本，操作我发送给你的数据副本，并返回给我你的结果的副本。

被调用的实体是否持有/拥有数据?然后REST:要么(1)向我展示你的一些数据的副本，要么(2)操纵你的一些数据。

归根结底，这是关于行为的哪一方拥有/持有数据。是的，您可以使用REST语言与基于RPC的系统进行通信，但是在这样做的时候仍然会执行RPC活动。

示例1:我有一个对象，它通过DAO与关系数据库存储(或任何其他类型的数据存储)通信。对于我的对象和数据访问对象(可以作为API存在)之间的交互，使用REST样式是有意义的。我的实体并不拥有/持有数据，而是关系数据库(或非关系数据存储)拥有。

例2:我需要做很多复杂的数学。我不想在我的对象中加载一堆数学方法，我只想将一些值传递给其他可以进行各种数学运算的东西，并得到一个结果。那么RPC样式就有意义了，因为数学对象/实体将向我的对象公开一大堆操作。请注意，这些方法可能都被公开为单独的api，我可以使用GET调用其中任何一个方法。我甚至可以声称这是RESTful的，因为我通过HTTP GET调用，但实际上它是RPC。我的实体拥有/持有数据，远程实体只是对我发送给它的数据副本执行操作。

它是使用http的RPC。REST的正确实现应该不同于RPC。拥有处理数据的逻辑(如方法/函数)就是RPC。getAllData()是一个智能方法。REST不能具有智能，它应该是可以通过外部情报查询的哑数据。

最近我看到的大多数实现都是RPC，但许多人错误地将其称为REST。REST和HTTP是救世主，SOAP和XML是恶棍。所以你的困惑是合理的，你是对的，它不是REST。但是请记住，REST不是新事物(2000年)，尽管SOAP/XML是旧的，json-rpc是后来才出现的(2005年)。

Http协议不做REST的实现。REST(GET, POST, PUT, PATCH, DELETE)和RPC(GET + POST)都可以通过HTTP进行开发(例如:通过visual studio中的web API项目)。

• 0级:Http POST
• 第1级:每个资源/实体都有一个URI(但仍然只有POST)
• 级别2:POST和GET都可以使用
• Level 3(RESTful):使用HATEOAS(超媒体链接)或者换句话说self 李探索性链接< / >

三级(HATEOAS):

1. Link表示该对象可以这样更新，也可以这样添加。

2. Link表示该对象只能被读取，这就是我们如何做的。

   显然，发送数据还不足以成为REST，但如何查询数据，也应该提到。但话说回来，为什么只有4个步骤呢?为什么不能只是步骤4，并将其称为REST呢?理查德森只是给了我们一个逐步实现的方法，仅此而已。

你已经建立了可供人类使用的网站。但是你能不能 建立可以被机器使用的网站?这就是未来

.

.

• 这本书rest式Web服务有帮助
• < a href = " https://apihandyman。一个非常有趣的阅读RPC vs REST . io/do-you-really-know-why-you-prefer-rest-over-rpc/" rel="noreferrer">

正如其他人所说，一个关键的区别是REST url以名称为中心，而RPC url以动词为中心。我只是想包括这个清晰的例子表来演示:

---------------------------+-------------------------------------+--------------------------
Operation                 | RPC (operation)                     | REST (resource)
---------------------------+-------------------------------------+--------------------------
Signup                    | POST /signup                        | POST /persons
---------------------------+-------------------------------------+--------------------------
Resign                    | POST /resign                        | DELETE /persons/1234
---------------------------+-------------------------------------+--------------------------
Read person               | GET /readPerson?personid=1234       | GET /persons/1234
---------------------------+-------------------------------------+--------------------------
Read person's items list  | GET /readUsersItemsList?userid=1234 | GET /persons/1234/items
---------------------------+-------------------------------------+--------------------------
Add item to person's list | POST /addItemToUsersItemsList       | POST /persons/1234/items
---------------------------+-------------------------------------+--------------------------
Update item               | POST /modifyItem                    | PUT /items/456
---------------------------+-------------------------------------+--------------------------
Delete item               | POST /removeItem?itemId=456         | DELETE /items/456
---------------------------+-------------------------------------+--------------------------

笔记

如表所示，REST倾向于使用URL路径参数来标识特定的资源 (例如GET /persons/1234)，而RPC倾向于为函数输入
使用查询参数 李(例如GET /readPerson?personid=1234)。< / >
• 表中没有显示REST API如何处理过滤，这通常涉及查询参数(例如GET /persons?height=tall)。
• 同样没有显示的是，在这两个系统中，当你做创建/更新操作时，额外的数据可能是通过消息体传入的(例如，当你做POST /signup或POST /persons时，你包括描述新人的数据)。
• 当然，这些都不是一成不变的，但它让您了解可能会遇到什么情况，以及如何组织自己的API以保持一致性。有关REST URL设计的进一步讨论，请参见这个问题。

这是我在不同的用例中理解和使用它们的方式:

例子:餐厅管理

REST的用例:订单管理

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

对于资源管理，REST是干净的。一个具有预定义操作的端点。这可以看作是一种向世界公开DB (Sql或NoSql)或类实例的方法。

实现的例子:

class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.

框架示例:用于python的Falcon。

RPC的用例:操作管理

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

对于分析性的、可操作的、非响应性的、非代表性的、基于动作的作业，RPC工作得更好，并且很自然地认为它是功能性的。

实现的例子:

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.


@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

框架示例:Flask for python

在HTTP上，它们都只是HttpRequest对象，它们都期望返回HttpResponse对象。我认为人们可以继续用这种描述来编码，而不用担心其他的事情。

这里有很多很好的答案。我仍然建议你去这谷歌博客，因为它确实很好地讨论了RPC &REST并捕获了我在这里的任何答案中都没有读到的东西。

我想引用同一链接中的一段话，这段话让我印象深刻:

REST本身是对支撑HTTP和全球web的设计原则的描述。但是因为HTTP是唯一具有商业重要性的REST API，所以我们基本上可以避免讨论REST，而只关注HTTP。这种替代是有用的，因为人们对REST在api上下文中的含义有很多困惑和变化，但是对于HTTP本身是什么有更清晰和一致的认识。HTTP模型是RPC模型的完美反面——在RPC模型中，可寻址的单元是过程，问题域的实体隐藏在过程后面。在HTTP模型中，可寻址的单元是实体本身，系统的行为隐藏在实体后面，作为创建、更新或删除它们的副作用

共享的URL看起来像RPC端点。 下面是RPC和REST的示例。希望这有助于理解什么时候可以使用它们

让我们考虑一个端点，它向客户发送应用程序维护中断电子邮件。

这个端点执行一个特定的操作。

RPC

POST https://localhost:8080/sendOutageEmails


BODY: {"message": "we have a scheduled system downtime today at 1 AM"}

休息

POST https://localhost:8080/emails/outage


BODY: {"message": "we have a scheduled system downtime today at 1 AM"}

在这种情况下，RPC端点更适合使用。当API调用执行单个任务或操作时，通常使用RPC端点。显然，我们可以使用REST，但端点不是很REST化的，因为我们没有对资源执行操作。

现在让我们看看在数据库中存储一些数据的端点。(典型CRUD操作)

RPC

POST https://localhost:8080/saveBookDetails


BODY: {"id": "123", "name": "book1", "year": "2020"}

休息

POST https://localhost:8080/books


BODY: {"id": "123", "name": "book1", "year": "2020"}

总而言之,

• RPC可用于执行单个特定操作的端点。
• 资源需要CRUD操作的端点的REST。