REST和RPC之间的Web服务差异

Question

我有一个Web服务,它接受JSON参数并具有方法的特定URL,例如:

http://IP:PORT/API/getAllData?p={JSON}

这绝对不是REST,因为它不是无状态的.它需要考虑cookie并拥有自己的会话.

是RPC吗？RPC和REST有什么区别？

Answer 1

请考虑以下HTTP API示例,该API用于对放置在餐馆中的订单进行建模.

• 该RPC API认为在"动词"的条款,露出餐厅的功能是接受参数的函数调用,并调用通过这似乎是最合适的HTTP动词这些功能-一个"得到"的查询,等等,但名字动词的内容纯粹是偶然的,并且与实际功能没有实际关系,因为您每次都在调用不同的URL.退货代码是手工编码的,也是服务合同的一部分.
• 该REST API,相反,模型中的问题域的资源范围内的各种实体,并使用HTTP动词来表示对这些资源交易- POST创建,PUT更新,并能读到. 在同一URL上调用的所有这些动词都提供不同的功能.常见的HTTP返回码用于传达请求的状态.

正在下单:

• RPC: http:// MyRestaurant:8080/Orders/PlaceOrder(POST:{Tacos object})
• REST:http:// MyRestaurant:8080/Orders/Order？OrderNumber = asdf(POST:{Tacos object})

检索订单:

• RPC: http:// MyRestaurant:8080/Orders/GetOrder？OrderNumber = asdf(GET)
• REST:http:// MyRestaurant:8080/Orders/Order？OrderNumber = asdf(GET)

更新订单:

• RPC: http:// MyRestaurant:8080/Orders/UpdateOrder(PUT:{Pineapple Tacos object})
• REST:http:// MyRestaurant:8080/Orders/Order？OrderNumber = asdf(PUT:{Pineapple Tacos object})

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

Answer 2

仅通过查看您发布的内容,您无法在REST或RPC之间明确区分.

REST的一个限制是它必须是无状态的.如果您有会话,那么您已拥有状态,因此您无法将服务称为RESTful.

您在URL(即getAllData)中有操作的事实表明RPC.在REST中,您可以交换表示,并且您执行的操作由HTTP谓词决定.此外,在REST中,不使用参数执行内容协商?p={JSON}.

不知道您的服务是否是RPC,但它不是RESTful.您可以在线了解差异,这里有一篇文章可以帮助您:揭开RPC和REST的神话.您更了解服务内部的内容,因此将其功能与RPC相比较,并得出您自己的结论.

Answer 3

As others have said, a key difference is that REST is noun-centric and RPC is verb-centric. I just wanted to include this clear table of examples demonstrating that:

---------------------------+-------------------------------------+--------------------------
 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       
---------------------------+-------------------------------------+--------------------------

Notes

• 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.

Answer 4

它是使用http的RPC。REST的正确实现应不同于RPC。具有逻辑来处理数据（例如方法/函数）的就是RPC。getAllData（）是一种智能方法。REST无法提供智能，应该将其转储为可以由外部智能查询的数据。

如今，大多数实现都是RPC，但许多人错误地将其称为REST，因为他们看到它们没有使用XML / Soap，而是使用HTTP + json。使用HTTP的REST是拯救者，使用XML的SOAP是恶棍。因此，您的困惑是有道理的，并且您是对的，这不是REST。

Http协议未实现REST。REST（GET，POST，PUT，PATCH，DELETE）和RPC（GET + POST）都可以通过HTTP（例如，通过Visual Studio中的Web API项目）进行开发。

RPC很老，每个学校的孩子都知道RPC是什么，可以理解，大多数REST开发的最终都是RPC（HTTP + Json）。但是什么是REST？理查森到期模型如下（概述）所示。只有级别3是RESTful。

• 0级：Http POST
• 级别1：每个资源/实体都有一个URI（但仍然只有POST）
• 级别2：POST和GET均可使用
• 级别3（RESTful）：使用HATEOAS（超级媒体链接）或换句话说就是自我探索链接

例如第3级：

1. 链接指出可以用这种方式更新和添加该对象

2. 链接指出只能读取此对象，这就是我们的操作方式。

   显然，发送数据不足以成为REST，但是还应该提到如何查询数据。但是再说一次，为什么要执行4个步骤？为什么不能仅将其称为“步骤4”并将其称为REST？理查森（Richardson）只是一步一步地达到了目标，仅此而已。

您已经建立了可供人类使用的网站。但是，您还可以建立可供机器使用的网站吗？那就是未来所在，RESTful Web Services向您展示了如何做到这一点。

• 本书RESTful Web Services 有助于
• 一个非常有趣的RPC vs REST阅读

Answer 5

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

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

该端点执行一项特定操作。

远程过程调用

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，如图所示，但端点不是非常 RESTful，因为我们没有对资源执行操作。

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

远程过程调用

POST https://localhost:8080/saveBookDetails

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

休息

POST https://localhost:8080/books

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

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

总而言之，

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

Slack 使用这种HTTP RPC Web API风格- https://api.slack.com/web

Answer 6

这里有很多很好的答案。我仍然建议您参考这个google 博客，因为它在讨论 RPC 和 REST 之间的差异方面做得非常好，并捕获了我在此处的任何答案中未读到的内容。

\n\n

我想引用同一个链接中令我印象深刻的一段话：

\n\n

\n

REST 本身是对支撑 HTTP 和万维网的设计原则的描述。但由于 HTTP 是唯一具有商业重要性的 REST API，因此我们基本上可以避免讨论 REST，而只关注 HTTP。这种替代很有用，因为人们对 API 上下文中 REST 含义的理解存在很多混乱和可变性，但对于 HTTP 本身的含义却更加清晰和一致。HTTP模型是RPC模型\xe2\x80\x94的完美逆，RPC模型中，可寻址单元是过程，问题域的实体隐藏在过程后面。在 HTTP 模型中，可寻址单元是实体本身，系统的行为隐藏在实体后面，作为创建、更新或删除实体的副作用。

\n

\n

Answer 7

最好将REST描述为与资源一起使用，其中RPC更多地是关于动作的。

REST 代表代表性状态转移。这是组织独立系统之间交互的一种简单方法。RESTful应用程序通常使用HTTP请求来发布数据（创建和/或更新），读取数据（例如进行查询）和删除数据。因此，REST可以对所有四个CRUD（创建/读取/更新/删除）操作使用HTTP。

RPC 基本上用于在不同模块之间进行通信以服务于用户请求。例如，在开放式堆栈中，例如引导虚拟机时nova，glance和中子如何协同工作。

Answer 8

我会这样争论：

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

被叫实体是否持有/拥有数据？然后 REST：要么 (1) 向我展示您的某些数据的副本，要么 (2) 操作您的某些数据。

最终是关于行动的哪一方拥有/持有数据。是的，您可以使用 REST 语言与基于 RPC 的系统进行对话，但是这样做时您仍然会进行 RPC 活动。

示例 1：我有一个对象，它通过 DAO 与关系数据库存储（或任何其他类型的数据存储）进行通信。对我的对象和可以作为 API 存在的数据访问对象之间的交互使用 REST 风格是有意义的。我的实体不拥有/持有数据，关系数据库（或非关系数据存储）拥有。

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