REST 与 JSON-RPC? [英] REST vs JSON-RPC?

问题描述

我正在尝试在 REST 和 JSON-RPC 之间进行选择，以便为 Web 应用程序开发 API.他们如何比较?

I'm trying to chose between REST and JSON-RPC for developing an API for a web application. How do they compare?

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

Update 2015: I have found REST easier to develop and use for an API which is served on Web/HTTP, because the existing and mature HTTP protocol which is understood by both client and server can be leveraged by the API. For example response codes, headers, queries, post bodies, caching and many other features can be used by the API without any additional effort or setup.

推荐答案

RPC 的根本问题是耦合.RPC 客户端以多种方式与服务实现紧密耦合，并且在不破坏客户端的情况下更改服务实现变得非常困难:

The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients:

• 客户需要知道过程名称；
• 过程参数顺序、类型和计数很重要.在不破坏客户端实现的情况下，在服务器端更改过程签名(参数数量、参数顺序、参数类型等...)并不容易；
• RPC 风格除了过程端点 + 过程参数之外不公开任何东西.客户无法确定下一步可以做什么.

另一方面，在 REST 风格中，通过在表示(HTTP 标头 + 表示)中包含控制信息来引导客户端非常容易.例如:

On the other hand in REST style it's very easy to guide clients by including control information in representations(HTTP headers + representation). For example:

• 嵌入链接关系类型注释的链接是可能的(实际上是强制性的)，这些链接关系类型传达了这些 URI 的含义；
• 客户端实现不需要依赖特定的过程名称和参数.相反，客户端依赖于消息格式.这为特定媒体格式(例如 Atom、HTML、Collection+JSON、HAL 等...)使用已经实现的库创造了可能性
• 只要它们仅依赖于注册的(或特定于域的)链接关系，就可以在不破坏客户端的情况下轻松更改 URI；
• 可以在表示中嵌入类似表单的结构，如果最终用户是人类，则客户可以将这些描述作为 UI 功能公开；
• 支持缓存是额外的优势；
• 标准化状态代码；

REST 方面还有更多不同之处和优势.

There are many more differences and advantages on the REST side.

这篇关于REST 与 JSON-RPC?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！