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

例子:餐厅管理

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

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

例子:餐厅管理

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

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

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

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

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

正如其他人所说，一个关键的区别是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       
---------------------------+-------------------------------------+--------------------------

笔记

As the table shows, REST tends to use URL path parameters to identify specific resources (e.g. GET /persons/1234), whereas RPC tends to use query parameters for function inputs (e.g. GET /readPerson?personid=1234). Not shown in the table is how a REST API would handle filtering, which would typically involve query parameters (e.g. GET /persons?height=tall). Also not shown is how with either system, when you do create/update operations, additional data is probably passed in via the message body (e.g. when you do POST /signup or POST /persons, you include data describing the new person). Of course, none of this is set in stone, but it gives you an idea of what you are likely to encounter and how you might want to organize your own API for consistency. For further discussion of REST URL design, see this question.

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

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

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

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

RPC

POST https://localhost:8080/sendOutageEmails

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

REST

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"}

REST

POST https://localhost:8080/books

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

REST对于这种情况(CRUD)要好得多。在这里，读取(GET)或删除(delete)或更新(PUT)可以通过使用适当的HTTP方法来完成。方法决定对资源(在本例中为“books”)的操作。 在这里使用RPC是不合适的，因为我们需要为每个CRUD操作(/getBookDetails， /deleteBookDetails， /updateBookDetails)设置不同的路径，并且必须为应用程序中的所有资源执行此操作。

总而言之,

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