REST和RPC之间的Web服务差异

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

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

这绝对不是REST，因为它不是无状态的。它考虑了cookie并具有自己的会话。

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

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

REST的一个限制是它必须是无状态的。如果您有一个会话，那么您就处于状态，因此您不能将您的服务称为RESTful。

您的网址（即getAllData）中有操作，这一事实表明RPC。在REST中，您交换表示形式，并且执行的操作由HTTP动词决定。另外，在REST中，不使用参数执行内容协商?p={JSON}。

不知道您的服务是否是RPC，但它不是RESTful的。您可以在线了解差异，这里有一篇文章可以帮助您入门：揭穿RPC和REST的神话。您会更好地了解服务内部的内容，因此可以将其功能与RPC进行比较，并得出自己的结论。

考虑下面的HTTP 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（输入：{Pineapple Tacos object}）
• REST：http：// MyRestaurant：8080 / Orders / Order？OrderNumber = asdf（PUT：{Pineapple Tacos object}）

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

就像其他人所说的，主要区别在于REST以名词为中心，而RPC以动词为中心。我只想包含这个清晰的示例表，以表明：

--------------------------- + ---------------------- --------------- + --------------------------
  操作                  | RPC（操作）                      | REST（资源）
--------------------------- + ---------------------- --------------- + --------------------------
 注册| POST /注册| POST /人           
--------------------------- + ---------------------- --------------- + --------------------------
 辞职 POST /辞职| 删除/人/ 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 读人| GET / readPerson？personid = 1234 | GET /人/ 1234       
--------------------------- + ---------------------- --------------- + --------------------------
 阅读人的物品清单| GET / readUsersItemsList？userid = 1234 | GET /人/ 1234 /项
--------------------------- + ---------------------- --------------- + --------------------------
 将项目添加到人员列表| POST / addItemToUsersItemsList | POST /人/ 1234 /项
--------------------------- + ---------------------- --------------- + --------------------------
 更新项目 POST / modifyItem | PUT /项目/ 456          
--------------------------- + ---------------------- --------------- + --------------------------
 删除项目| POST / removeItem？itemId = 456 | 删除/ 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设计的进一步讨论，请参阅此问题。

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

这些天我看到的大多数实现都是RPC，但许多人误将其称为REST。使用HTTP的REST是拯救者，使用XML的SOAP是恶棍。因此，您的困惑是有道理的，并且您是对的，这不是REST。

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

很好，但是REST是什么？理查森到期模型如下（概述）所示。只有级别3是RESTful。

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

例如：3级（HATEOAS）：

1. 链接状态可以用这种方式更新和添加该对象。

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

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

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

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

PS：REST超级流行，因此自动化测试也是如此，但在实际示例中，..很好..

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

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

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

因此，我会争辩：

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

被叫实体是否拥有/拥有数据？然后进行REST：（1）向我显示您的某些数据的副本，或者（2）处理您的某些数据。

最终，它是关于操作的哪一侧拥有/保存数据的信息。是的，您可以使用REST语言与基于RPC的系统进行通信，但是这样做仍将继续进行RPC活动。

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

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

通过HTTP，它们最终都只是HttpRequest对象，并且都希望HttpResponse返回对象。我认为人们可以继续使用该描述进行编码，而不必担心其他事情。

这里有很多很好的答案。我仍然会向您推荐这个 Google博客，因为它在讨论RPC和REST之间的区别方面做得非常好，并且捕获了我在此处的任何答案中都没有读到的内容。

我会引用引人注意的同一链接中的一段：

REST本身是对支撑HTTP和万维网的设计原则的描述。但是，因为HTTP是唯一在商业上重要的REST API，所以我们几乎可以避免讨论REST，而只关注HTTP。这种替换很有用，因为人们认为REST在API上下文中的含义存在很多混乱和可变性，但是对于HTTP本身是什么却有更大的清晰度和共识。HTTP模型是RPC模型的完美反面-在RPC模型中，可寻址单元是过程，而问题域的实体则隐藏在过程的后面。在HTTP模型中，可寻址单元是实体本身，系统的行为隐藏在实体后面，这是创建，更新或删除它们的副作用。

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

示例：餐厅管理

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.

框架示例：适用于python的烧瓶