什么时候 JSON-RPC over http 和 POST 比 RESTful API 更合适？答案

【问题标题】：When is JSON-RPC over http with POST more suitable than RESTful API?什么时候 JSON-RPC over http 和 POST 比 RESTful API 更合适？
【发布时间】：2017-12-15 15:01:13
【问题描述】：

我目前正在与一位高级开发人员一起开发一个 Web 应用程序。我们已经同意使用 REST API 进行客户端-服务器通信，他向我发送了参数和预期的响应。

但设计似乎不是 RESTful。相反，它看起来像 JSON-RPC over http，仅使用 POST 方法。

例如，要注册一个用户，您需要向服务器发送一个 POST 请求，其中包含以下参数。

{
  id: 1,
  method: "RegisterUser",
  params: {
    firstName: "John",
    lastName: 'Smith',
    country: 'USA',
    phone: "~",
    email: "~",
    password: "~"
  }
}

而预期的反应是

{
  id: 1
  result: "jwt-token",
  error : null 
}

多个请求被发送到同一个 URL，服务器根据参数中的“方法”发回响应。例如，要获取用户信息，您可以向同一 URL 发送 { method: "GetUserInfo", params: { id: ~ }}。所有响应的状态码都是 200，错误由响应正文中的错误处理。所以即使状态码是200，如果error不为null就说明有问题。

我习惯做的方式是在注册新用户时向“users/”发送带有请求正文的 POST 请求，向“users/1”发送 GET 请求以检索用户信息等。

当我问他为什么决定这样做时，他在上一份工作中说，在遵循 RESTful API 设计时，尝试添加越来越多的 API 是一件痛苦的事情。此外，他说他不明白为什么 RESTful API 使用不同的 HTTP 动词，而所有这些动词都可以用 POST 完成。

我试图通过 POST 提出 REST API over JSON-RPC over http 的优点。

GET请求被浏览器缓存，但有些浏览器可能不支持POST请求缓存。
如果我们要将 API 开放给外部开发人员，这可能会让他们感到不适，因为这不是典型的 REST API。

在什么情况下 JSON-RPC over http 风格比 REST RESTful API 更好？或者它只是无关紧要，只是一个偏好问题？

【问题讨论】：

REST vs JSON-RPC?的可能重复
@Palpatim 我看过这个帖子，但它并没有真正回答我的问题。

标签： rest api json-rpc

【解决方案1】：

它看起来像 JSON-RPC over http 仅使用 POST 方法。

是的，确实如此。

我习惯做的方式是在注册新用户时向“users/”发送带有请求正文的 POST 请求，向“users/1”发送 GET 请求以检索用户信息等。

这也不完全是。

谜语。您是如何将这个问题提交到堆栈溢出的？好吧，您可能关注了您保存的书签，或者关注了来自谷歌的链接。也许你提交了一两次搜索，最终你点击了“”，它把你带到了一个表单。填写表格的详细信息后，您点击提交按钮。这使您看到了您的问题，其中包括（除其他外）用于编辑问题的链接。你对此不感兴趣，所以你已经完成了 - 除了不时刷新页面希望得到答案。

这是一个 REST api。您，代理，跟随从一个状态到另一个状态的链接，协商堆栈溢出“提交问题”协议。

除其他需要注意的事项外：浏览器 不需要事先知道要将内容发送到哪些 URL，或使用哪种 http 方法，因为 HTML 已将这些指令编码到其中。浏览器只需要了解 HTML 标准，就可以了解如何在表示中找到链接/表单。

现在，REST 只是一组架构约束，归结为“以 Web 服务器的方式进行操作”。您不需要使用 HTML 作为您的媒体类型；您无需将 Web 浏览器设计为您的客户。但是，要进行 REST，您确实需要超媒体；以及了解该超媒体类型的客户，因此您可以更轻松地选择其中一种标准化媒体类型。

还有更多的理由让我更喜欢 RESTful API 而不是 JSON-RPC 而不是 http 和 POST？还是没关系？

Roy Fielding, in 2008，提供了这个简单而正确的观察

REST 适用于跨多个组织的长期基于网络的应用程序。如果您认为不需要约束，请不要使用它们。

例如，GraphQL 的工作人员认为 REST 约束所产生的属性对其用例没有价值；远不如能够向客户提供根据客户特定需求调整的代表。

课程用马。

【讨论】：

感谢您的详细解释。但是，看着你的回答，我想我应该这样改写我的问题。在什么情况下 JSON-RPC over http 风格比 REST RESTful API 更好？

【解决方案2】：

当您对资源执行标准的创建、读取、更新和删除操作时，请使用 RESTful API。 CRUD 操作对每个资源的行为方式应该相同，除非您有一些前后挂钩。如果您的 API 遵循标准，任何加入该项目的新开发人员都会很容易理解它。

当您执行不一定完全映射到任何 CRUD 的操作时，请使用 JSON-RPC。例如，您可能想要检索特定资源集合的计数或摘要数据。您可以使用 REST 来做到这一点，但它可能需要您将其视为您从中读取的某种“摘要”资源。使用 JSON-RPC 更容易，因为您只需实现一个在数据库中运行适当查询并返回适当结果对象的过程。

或者，如果您想进行 API 调用，让用户删除或更新满足某些条件的资源的所有实例，而无需提前知道这些实例是什么，该怎么办？

如果您需要对标准 CRUD 操作产生大量副作用，并且在每个操作之前或之后运行钩子不方便，您也可以使用 JSON-RPC。

您不必完全使用其中之一，您可以同时使用两者。在适当的地方有标准的 RESTful 端点和另一个 RPC 端点来处理 JSON-RPC 调用。

【讨论】：