彻底理解 RESTful

内容转载于https://zhuanlan.zhihu.com/p/37980590

内容列表

• REST 的出处
• REST 的概念
• REST 的推导与其特征
• REST 与 HTTP 、URI 的关系
• REST 的使用示例与描述
• 开发 RESTful API 的流行框架
• 总结

 

REST 的出处

 

REST 这个概念是　Roy Thomas Fielding 2000　年在加州大学欧文分校 (UNIVERSITY OF CALIFORNIA, IRVINE)　的　博士论文　中提出。在该论文中作者讨论和比较了传统基于网络应用架构的一些特点，传统架构的的缺点在于随着系统的进化组件的独立性和扩展性以及跨平台跨语言有很大局限性,在这样的前提下作者提出了　REST 概念, REST　用于指导设计和开发 Web 体系架构。所以 REST 只是一个架构思想，不是任何技术,就像作者在论文中提到的

• REST, a novel architectural style for distributed hypermedia systems; and,(REST,一种新颖的分布式超媒体系统的架构风格)

 

REST 的概念

 

在网上搜索 RESTful 出现的最多的一个词就是 "表现层状态转移",如果没有真正了解 REST 或者 HTTP 看到这句话马上得到一个结果: "这句话不是说给人听的"。在论文中作者对于这个概念是这样说的:

The name "Representational State Transfer" is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.

"Representational State Transfer" 旨在提醒人们设计良好的 web 应用行为应该是: 用户在一个 web 页面，通过点击一个链接,服务器返回下一个页面。

如果到这里, 依然云里雾里，很正常，接下来请抛开这个概念。讨论一些看似无关的问题，最后返回来理解这句话。

 

REST 的推导与其特征

 

在论文开始论文 摘要 中,作者这样提到:

The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system. The Web has been iteratively developed over the past ten years through a series of modifications to the standards that define its architecture. In order to identify those aspects of the Web that needed improvement and avoid undesirable modifications, a model for the modern Web architecture was needed to guide its design, definition, and deployment.

www 万维网的成功很大程度上在于其软件架构满足了可伸缩的分布式超媒体系统的需要。网络一直迭代开发在过去的十年里通过一系列修改标准,定义它的架构。为了确定网络的哪些方面需要改进和避免不必要的修改,需要一个现代Web体系结构模型来指导其设计、定义和部署。

作者参与了 HTTP/1.0　和 URI　的设计，在此过程中认识到需要为万维网如何工作提供一个模型，这个模型就是 REST。REST　架构旨在提高组件的独立性和伸缩性和置换性。例如:　之前传统 web　应用架构模式基本是这样:在论文中第五节，作者叫做　Null Style (零架构)

Null Style 零架构

所谓的零架构，没有明显的组件交互,像早期的静态网站所有内容都是静态 html 网页，后来的动态生成　html, java　中的 springmvc struts 等。即使像　springmvc 这样的架构本质上数据模块(数据组件)与显示层(显示组件)依然是耦合在一块。如果随着业务的发展，显示组件的跨平台性，数据组件的可伸缩性与独立性，这些基于网络应用的重要因素(跨平台，可伸缩)都无法体现。

Client-Server 客户端-服务端架构

在 Null Style (零架构)的基础上进入一步推导到 Client-Server 架构: 将显示组件与数据组件分割

这种架构解决了零架构的显示组件跨平台与数据组件的可伸缩与独立性。客户端可以根据需要添加新的客户端，旧的服务器接口对于新客户端依然有效。服务端可以根据业务需要扩展新的服务端，通过负载均衡为客户端提供服务，服务端的添加或者修改客户端无法感知，这解决了数据组件的独立性和扩展性。

Client-stateless-Server 架构

在　Client-Server 架构的基础上进一步推导到 Client-stateless-Server 架构: 客户端与服务端的交互必须是无状态的，像　http 协议那样

 

stateless (无状态)交互意味着每次请求是独立的，每次请求无法感知和依赖另一个请求的存在，这保证了请求的可靠性。由于服务器无需存储请求之间的状态和管理请求之间的资源信息使得服务端更加简单。但是也造成一个问题就是由于每次请求都是独立的，所以每次请求都需要携带所有需要的信息因为服务端不保存之前请求的状态和资源信息，所以会造成网络性能降低和携带重复的数据。

Client-cache-stateless-Server 架构

在 Client-stateless-Server 架构的基础上进一步推导到 Client-cache-stateless-Server 架构: 在客户端添加缓存机制解决或者抵消这种架构模式带来的性能缺陷，客户端可以通过缓存重用重复的响应。

统一接口

在基于网络的　REST 架构风格重点强调接口的统一: 服务端需要提供标准的可见接口，保证其他系统可见，保证每个系统独立发展。论文中作者为统一的接口提出四点指导原则:

1. identification of resources (标识资源),通过 URI 唯一标识资源
2. manipulation of resources through representations (资源的操作方式标识)操作资源的方式，通过 HTTP POST、GET、...
3. self-descriptive messages (自描述信息)客户端请求需要告诉接受什么样的格式，是否缓存
4. hypermedia as the engine of application state (超媒体是应用表述的核心)

 

以上四点: Client-Server (客户端-服务端)、Stateless (无状态)、Cache(可缓存)、统一接口。是作者在论文中提到的 REST 四个特点，REST 为了进一步满足对于互联网的可伸缩的要求,作者还提到了系统的分层设计和按需编码。

分层设计

按需编码

以上便是作者在论文中根据传统架构设计的过程，推导出 REST 架构应该具有的几个特点: 客户端-服务端模型、无状态、可缓存、统一接口、分层系统、按需编码

在论文最后，作者这样写到: REST 架构试图为现代 web 架构提供一个指导原则,它试图最小化网络延迟，同时最大化组件的独立性和可伸缩性,以满足分布式超媒体系统对于可伸缩网络的需要。

这样的架构风格就是 REST

 

REST 与 HTTP 、 URI 的关系

 

作者在论文第六节有提到 www 万维网就是 REST 的最好实践,HTTP 和 URI 就是 REST 的实践。回想一下作者对于 "Representational State Transfer"　的定义:"旨在提醒人们基于网络的应用最好的设计就是: 在一个 web 页面中,用户点击一个链接，然后为用户返回下一个页面。"这个概念是万维网的本质,万维网之所以成功就在于通过 link (链接) 将文档链接，用户通过点击链接获取文档。那么试想是不是我们对于资源（图片、文本、json、xml ...）的获取，是不是也应该与 linke (链接)的初衷更加契合，这样会使得我们系统的架构设计更加符合网络应用的可伸缩的需求。

REST 使用 HTTP 作为各组件的交流协议,使用 URI 作为资源定位, 数据的组织形式可以采用流行的格式例如: json 或者 xml 等。

 

REST 的使用示例和描述

 

如下图就是使用 REST 架构的典型示例,客户端(IOS、Android、Angular...) 与数据业务（Business Logic & Service）分离，这符合 Client-Server ,数据业务和服务更加独立和更大可伸缩性，客户端拥有跨平台跨语言的特征。这张图展现了 REST 架构的宏观信息。

 

 

下图展现了 REST 架构中服务端 API 接口的微观信息:

接口通过 URI 唯一标识了资源(task),这符合 REST 接口统一的第一条原则（资源唯一标识）。通过 HTTP 不同方法定义了操作该资源的方式,这符合接口统一的第二条规则(资源的操作方式标识)。因为 REST 是以资源为对象，所以接口设计时 URI 的设计应该使用名词不要使用动词至于操作的方式原则第二条可以指定，URI 的功能在于标识资源的唯一性而不需要体现操作方式信息。REST 的数据组织方式可以使用流行的数据格式(json、xml....)目前最流行的是使用 json。

 

开发 RESTful API 的流行框架

 

支持开发 RESTful API 的框架 java 有

• Jersey
• Resteasy
• SpringMVC
• ....

其他语言就不列举了.

关于如何设计良好的 RESTful API 最佳实践可以看这篇文章: 良好的 RESTful API 设计原则

 

总结

 

REST 架构将处理对象抽象为资源通过 URI 唯一标识资源地址，使用 HTTP 作为传输协议，使用流行数据格式作为数据组织方式。各组件通过统一接口交互，使得各组件尽可能独立和可伸缩满足基于网络的分布式超媒体系统可伸缩网络的需要。在我自己理解而言， REST 的灵魂所在正像作者在论文中提到的那样,旨在提醒设计良好的网络应用就像万维网超链接那样，在一个页面用户点击一个链接为用户返回下一个页面,在 REST 中这个链接就是 REST API 的 URI 地址，这样的设计使得互联网上的所有资源都更像万维网中的　link （链接），你只要点击它就会获得新的资源，更加契合万维网的本质。如果这样理解，再返回去看　"表现层状态转移" 这个概念就不是那么难以理解了。