REST与JSON-RPC？[关闭]

我试图在REST和JSON-RPC之间进行选择，以开发用于Web应用程序的API。他们如何比较？

2015年更新：我发现REST更易于开发和使用Web / HTTP上提供的API，因为该API可以利用客户端和服务器都能理解的现有和成熟的HTTP协议。例如，API可以使用响应代码，标头，查询，帖子正文，缓存和许多其他功能，而无需进行任何额外的工作或设置。

RPC的基本问题是耦合。RPC客户端通过几种方式与服务实现紧密耦合，并且在不破坏客户端的情况下更改服务实现变得非常困难：

• 客户必须知道过程名称；
• 程序参数的顺序，类型和计数很重要。在不破坏客户端实现的情况下，在服务器端更改过程签名（参数数量，参数顺序，参数类型等）并不是那么容易。
• RPC样式除了过程端点+过程参数外，不公开任何内容。客户无法确定下一步可以做什么。

另一方面，在REST风格中，通过在表示形式（HTTP标头+表示形式）中包含控制信息来引导客户端非常容易。例如：

• 有可能（实际上是强制性的）嵌入带有链接关系类型的注释，这些链接关系类型传达了这些URI的含义；
• 客户端实现不需要依赖特定的过程名称和参数。相反，客户端取决于消息格式。这样就可以将已经实施的库用于特定的媒体格式（例如Atom，HTML，Collection + JSON，HAL等）。
• 只要只依赖已注册的（或特定于域的）链接关系，就可以轻松更改URI而不会破坏客户端。
• 可以将类似表单的结构嵌入表示中，如果最终用户是人类，则客户可以将这些描述作为UI功能公开。
• 支持缓存是另一个优势。
• 标准化状态代码；

REST方面还有许多其他的区别和优点。

我已经详细研究了这个问题，并决定即使我的大多数应用程序都是CRUD应用程序，纯REST也太过局限了，而RPC最好。如果您坚持使用REST，那么最终您将不知所措，想知道如何才能为某些特殊目的轻松地向API添加另一个所需的方法。在许多情况下，使用REST的唯一方法是为其创建另一个控制器，这可能会使程序过度复杂化。

如果决定使用RPC，则唯一的区别是您将动词明确指定为URI的一部分，该动词清晰，一致，错误较少​​，而且实际上没有问题。特别是如果您创建的应用程序超出了简单的CRUD，RPC是唯一的选择。我对RESTful的纯粹主义者还有另一个问题：HTTP POST，GET，PUT，DELETE在HTTP中具有明确的含义，这些含义已被REST转换为其他含义，仅仅是因为它们在大多数时间（而不是所有时间）都适用。

在编程中，我很久以前发现，试图用一件事来表示两件事会在某个时候出现并咬住你。我喜欢能够对几乎所有操作使用POST，因为它提供了您的方法需要执行的发送和接收数据的自由。您不可能使整个世界都适应CRUD。

首先，HTTP-REST是一种“代表性状态转移”架构。这意味着很多有趣的事情：

• 您的API将是无状态的，因此更容易设计（忘记复杂的自动机中的转换真的很容易），并与独立的软件部件集成。
• 您将被设计为安全的读取方法，这将易于缓存和集成。
• 您将被设计为幂等的设计写方法，这将更好地处理超时问题。

其次，HTTP-REST与HTTP完全兼容（请参阅上一部分中的“安全”和“幂等”），因此您将能够重用HTTP库（每种现有语言都存在）和HTTP反向代理，这将为您提供能够使用零行代码实现高级功能（缓存，身份验证，压缩，重定向，重写，日志记录等）。

最后但并非最不重要的一点是，根据HTTP 1.1的设计者（也是REST的发明者），使用HTTP作为RPC协议是一个巨大的错误：http：//www.ics.uci.edu/~fielding/pubs/dissertation/evaluation。 htm＃sec_6_5_2

好的答案-只是想澄清一些评论。JSON-RPC快速且易于使用，但是如上所述，资源和参数紧密耦合，并且倾向于使用GET / POST依赖动词（api / deleteUser，api / addUser），因为REST提供了松散耦合的资源（api /用户）在HTTP REST API中依赖于几种HTTP方法（GET，POST，PUT，PATCH，DELETE）。REST对于没有经验的开发人员来说很难实现，但是现在这种风格已经相当普遍了，从长远来看，它提供了更多的灵活性（使您的API的寿命更长）。

除了没有紧密耦合的资源外，REST还使您避免提交单一的内容类型-这意味着如果您的客户端需要接收XML或JSON甚至YAML数据，则可以将其固定在系统中返回任何使用content-type / accept标头的内容。

这使您可以保持API足够灵活以支持新的内容类型或客户端要求。

但是，真正将REST与JSON-RPC区别开的是，它遵循一系列经过深思熟虑的约束-确保体系结构的灵活性。这些限制包括确保客户端和服务器能够彼此独立地发展（您可以进行更改而不会弄乱客户端的应用程序），调用是无状态的（状态通过超媒体表示），提供用于交互的统一接口， API是在分层系统上开发的，响应可以由客户端缓存。对于按需提供代码还有一个可选的约束。

但是，尽管如此，但MOST API并不是RESTful的（根据Fielding），因为它们没有合并超媒体（响应中的嵌入式超文本链接可以帮助浏览API）。您会发现，大多数API都类似于REST，因为它们遵循REST的大多数概念，但是忽略了此约束。但是，越来越多的API正在实现此功能，这已成为主流实践。

这还为您提供了一些灵活性，因为超媒体驱动的API（例如Stormpath）将客户端定向到URI（这意味着如果发生某些更改，在某些情况下您可以修改URI而不会产生负面影响），而RPC URI必须是静态的。使用RPC，您还需要广泛地记录这些不同的URI，并说明它们如何相互关联。

总的来说，如果您想构建一个可持久的，可扩展的，灵活的API，我会说REST是必经之路。因此，我会说这是99％的时间都可以走的路。

麦克，祝你好运

IMO，关键是行动与资源导向。REST是面向资源的，非常适合CRUD操作，并且REST的已知语义为第一个用户提供了一定的可预测性，但是当从方法或过程中实施时，将迫使您向资源中心世界提供人工翻译。另一方面，RPC非常适合面向操作的API，在这些API中，您公开服务而不是可CRUD的资源集。

毫无疑问，REST更流行，如果要将API公开给第三方，这无疑会增加一些要点。

如果不是这样（例如，在SPA中创建AJAX前端的情况下），我的选择是RPC。特别是JSON-RPC，结合了JSON模式作为描述语言，并根据用例通过HTTP或Websocket进行了传输。

JSON-RPC是一个简单而优雅的规范，它定义了要在同步或异步RPC中使用的请求和响应JSON有效负载。

JSON Schema是草案规范，定义了旨在描述JSON数据的基于JSON的格式。通过使用JSON Schema描述服务输入和输出消息，您可以在不损害可用性的情况下在消息结构中拥有任意复杂度，并且可以使服务集成自动化。

传输协议（HTTP与Websocket）的选择取决于不同的因素，对于您是否需要HTTP功能（缓存，重新验证，安全性，幂等，内容类型，多部分...）或应用程序是否需要互换，这是最重要的高频率的邮件。

到目前为止，这在很大程度上还是我的个人观点，但是现在，对于那些阅读以下内容的Java开发人员而言，这确实很有帮助，这是我去年工作的框架，源于您现在想知道的相同问题：

http://rpc.brutusin.org

您可以在此处看到一个实时演示，其中显示了用于功能测试的内置资源库浏览器（感谢JSON Schema）和一系列示例服务：

http://demo.rpc.brutusin.org

希望对您有帮助！

纳乔

如果您的服务仅适用于模型和GET / POST / PUT / DELETE模式，请使用纯REST。

我同意HTTP最初是为无状态应用程序设计的。

但是对于要使用Websockets（通常暗示有状态）的现代，更复杂（！）的实时（web）应用程序，为什么不同时使用两者呢？Websockets上的JSON-RPC非常轻巧，因此您具有以下优点：

• 每个客户端上的即时更新（定义您自己的服务器到客户端RPC调用以更新模型）
• 易于添加复杂性（尝试仅使用REST制作Etherpad克隆）
• 如果操作正确（仅将RPC作为实时的附加功能添加），大多数功能仍仅可用于REST（除非主要功能是聊天或其他功能）

当您仅设计服务器端API时，首先定义REST模型，然后根据需要添加JSON-RPC支持，从而将RPC调用的数量保持在最少。

（并且对括号过度使用表示抱歉）

过去，我一直是REST的忠实拥护者，与RPC相比，它具有许多优点。您可以为客户端提供不同的内容类型，缓存，HTTP状态代码的重用，可以通过API引导客户端，并且如果文档不是很容易解释的话，您可以将文档嵌入API。

但是我的经验是，在实践中这并不能解决问题，相反，您需要做很多不必要的工作才能使一切正确。同样，HTTP状态代码通常不能完全正确地映射到您的域逻辑，因此在上下文中使用它们通常会感到有些强迫。但是我认为关于REST的最糟糕的事情是，您花费大量时间来设计资源以及它们所允许的交互。而且，每当您对API进行一些重大添加时，您都希望找到添加新功能的好方法，并且还没有将自己设计成一个角落。

这对我来说通常感觉是在浪费时间，因为大多数时候我已经对如何将API建模为一组远程过程调用有了一个很好的认识。而且，如果我已尽一切努力在REST约束内对问题进行建模，那么下一个问题是如何从客户端调用它？我们的程序基于调用过程，因此轻松构建良好的RPC客户端库，构建良好的REST客户端库就不那么容易了，在大多数情况下，您只需从服务器上的REST API映射回客户端中的一组过程即可。图书馆。

因此，今天对我来说，RPC感觉更简单，更自然。我真正想念的是一个一致的框架，该框架使编写自描述且可互操作的RPC服务变得容易。因此，我创建了自己的项目，尝试使用新方法使自己更容易使用RPC，也许其他人也觉得它很有用：https：//github.com/aheck/reflectrpc

根据理查森成熟度模型，问题不是REST与RPC，而是REST多少？

从这个角度来看，对REST标准的合规性可以分为4级。

• 0级：根据动作和参数进行思考。如本文所述，这在本质上等效于JSON-RPC（本文针对XML-RPC进行了解释，但是两者都适用相同的参数）。
• 级别1：根据资源进行思考。与资源相关的所有内容都属于同一个网址
• 级别2：使用HTTP动词
• 3级：HATEOAS

根据REST标准的创建者，只有3级服务可以称为RESTful。但是，这是合规性的指标，而不是质量。如果只想调用一个进行计算的远程函数，则在响应中具有相关的超媒体链接可能毫无意义，也不能根据所使用的HTTP动词来区分行为。因此，此类调用本质上倾向于更像RPC。但是，较低的遵从性级别不一定意味着有状态或较高的耦合。可能，您应该使用尽可能多的REST，而不是更多，而不是考虑REST与RPC。不要仅仅为了符合RESTful合规性标准而扭曲您的应用程序。

为什么使用JSON RPC：

对于REST API，我们必须为可能需要的每种功能/方法定义一个控制器。因此，如果我们要让客户端访问10个方法，则必须编写10个控制器以将客户端的请求与特定方法接口。

另一个因素是，即使我们为每种方法/功能使用不同的控制器，客户端也必须记住使用POST或GET的方式。这使事情进一步复杂化。最重要的是，如果使用POST，则必须设置请求的内容类型才能发送数据。

在JSON RPC的情况下，由于大多数JSONRPC服务器在POST HTTP方法上运行，并且内容类型始终为application / json，因此事情大大简化了。这减轻了记住在客户端使用正确的HTTP方法和内容设置的负担。

不必为服务器要向客户端公开的不同方法/功能创建单独的控制器。

为什么选择REST：

您具有服务器要向客户端公开的不同功能的单独URL。结果，您可以嵌入这些URL。

这些要点中的大多数是有争议的，并且完全取决于人的需要。

我认为，一如既往，这取决于...

REST具有广泛的公共支持的巨大优势，这意味着很多工具和书籍。如果您需要制作供不同组织的大量消费者使用的API，那么这样做是出于一个原因：它很流行。作为协议，由于将命令映射到URL /动词/响应的方式太多了，因此当然是完全失败的。

因此，当您编写需要与后端通信的单页Web应用程序时，我认为REST太复杂了。在这种情况下，您无需担心长期兼容性，因为该应用程序和API可以一起发展。

我曾经为单页Web应用程序开始使用REST，但是Web应用程序与服务器之间的细粒度命令很快使我发疯。我应该将其编码为路径参数吗？在身体里？查询参数？标头？在完成URL / Verb / Response设计之后，我不得不用Javascript编码这种混乱，用Java解码器编码，然后调用实际方法。尽管有很多工具可以使用，但是在域代码中不获取任何HTTP语义确实很棘手，这确实是一种不好的做法。（凝聚）

尝试为中等复杂的站点制作Swagger / OpenAPI文件，并将其与描述该文件中远程过程的单个Java接口进行比较。复杂性的增加是惊人的。

因此，我将单页webapp从REST切换到JSON-RPC。我开发了一个微型库，该库对服务器上的Java接口进行了编码，并将其运送到浏览器。在浏览器中，这为应用程序代码创建了一个代理，该代理返回了每个功能的承诺。

同样，REST之所以占有一席之地，只是因为它很有名，因此得到了很好的支持。认识潜在的无状态资源理念和层次模型也很重要。但是，这些原理可以很容易地在RPC模型中使用。JSON RPC通过HTTP运行，因此在该领域具有REST的相同优势。所不同的是，当您不可避免地遇到与这些原理不太匹配的这些功能时，您不会被迫做很多不必要的工作。

REST与HTTP紧密结合，因此，如果仅通过HTTP公开API，则REST更适合大多数（但不是全部）情况。但是，如果您需要通过其他传输方式（例如消息传递或Web套接字）公开API，则REST不适用。

最好在REST和JSON-RPC之间选择JSON-RPC，以开发易于理解的Web应用程序API。首选JSON-RPC，因为它可以轻松理解到方法调用和通信的映射。

选择最合适的方法取决于约束条件或主要目标。例如，就性能而言，建议使用JSON-RPC（例如，高性能计算）。但是，如果主要目的是不可知论以便提供可被其他人推断的通用接口，则建议使用REST。如果两个目标都需要实现，建议同时包含两个协议。

实际上将REST与JSON-RPC分开的事实是，它遵循了一系列经过深思熟虑的约束-确认了体系结构的灵活性。约束条件包括确保客户端和服务器能够彼此独立增长（可以在不影响客户端应用程序的情况下进行更改），调用是无状态的（状态被视为超媒体），统一提供了用于交互的接口，API在分层系统上得到了改进（Hall，2010年）。JSON-RPC快速且易于使用，但是如上所述，资源和参数紧密耦合，并且很可能依赖使用GET / POST的动词（api / addUser，api / deleteUser），而REST则提供松散耦合的资源（api / users）。REST API取决于几种HTTP方法，例如GET，PUT，POST，DELETE和PATCH。

JSON（表示为JavaScript Object Notation）是一种轻量级的数据交换格式，使人类易于阅读和书写。机器解析和生成它很容易。JSON是一种文本格式，它完全独立于语言，但是遵循惯例的惯例，适用于该语言家族的程序员，包括C＃，C，C ++，Java，Perl，JavaScript，Python和许多其他语言。这些属性使JSON成为一种完美的数据交换语言，并且是一个更好的选择。

错误的问题：强加了不存在的manichean！

您可以将JSON-RPC与“较少动词”（无方法）一起使用，并保留sendo ID，参数，错误代码和警告消息所需的最低标准。JSON-RPC标准没有说“您不能成为REST”，只是说了如何打包基本信息。

存在“ REST JSON-RPC”！是具有“最佳实践”的REST，它具有简单而可靠的合同，可最大限度地减少信息打包。

例

（从这个答案和教学背景出发）

在处理REST时，通常可以从资源考虑开始。在这种情况下，资源不仅是“银行帐户”，而且是该银行帐户的交易...但是JSON-RPC并不强制使用“ method”参数，所有参数均由端点的“ path”编码。

• REST 存款 与POST /Bank/Account/John/Transaction用JSON请求{"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}。
  JSON响应可以是{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST 撤柜与POST /Bank/Account/John/Transaction...相似。

• …… GET /Bank/Account/John/Transaction/12345@13这可能会返回该确切交易的JSON记录（例如，您的用户通常希望记录其帐户上的借方和贷方）。像{"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}。关于（REST）GET请求的约定可以包括通过“ @id”对id进行编码，因此不需要发送任何JSON，但仍在响应包中使用JSON-RPC。

如果您请求资源，那么RESTful API在设计上会更好。如果您需要一些简单的CRUD以外的带有许多参数和复杂方法的复杂数据，那么RPC是正确的方法。

我将vdata用于RPC协议：http ://vdata.dekuan.org/

1，PHP和JavaScript都可以。2，跨域资源共享（CORS）调用仍然可以。