REST和RESTful的理解

悠悠 2024-04-17 06:27 18阅读 0赞

# REST和RESTful的理解 #

[REST服务与RestfulAPI风格][REST_RestfulAPI]

## REST ##

REST 是[Roy Thomas Fielding][]提出的互联网软件的架构原则，定名为REST，即Representational State Transfer的缩写。翻译是"表现层状态转化"。

## RESTful ##

`RESTful`是一种风格。`Restful风格`一般用来描述各种API，符合这种风格的API被称为 `RESTful API`。

## RESTful API 设计指南 ##

[RESTful API 设计指南][RESTful API]

## REST系统特征 ##

[https://blog.csdn.net/qq\_21383435/article/details/80032375][https_blog.csdn.net_qq_21383435_article_details_80032375]

`客户-服务器（Client-Server）`，提供服务的服务器和使用服务的客户需要被隔离对待。

`无状态（Stateless）`，来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。

`可缓存（Cachable）`，服务器必须让客户知道请求是否可以被缓存。（Ross：更详细解释请参考 理解本真的REST架构风格 以及 StackOverflow 的这个问题 中对缓存的解释。）

`分层系统（Layered System）`，服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。

`统一接口（Uniform Interface）`，客户和服务器之间通信的方法必须是统一化的。（Ross：GET,POST,PUT.DELETE, etc）

`支持按需代码（Code-On-Demand，可选）`，服务器可以提供一些代码或者脚本（Ross：Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（Ross：比如客户可以在客户端下载脚本生成密码访问服务器。）

## 理解REST ##

[http://www.ruanyifeng.com/blog/2011/09/restful.html?bsh\_bid=1717507328][http_www.ruanyifeng.com_blog_2011_09_restful.html_bsh_bid_1717507328]

### 资源（Resources） ###

`REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。`  
REST的名称"表现层状态转化"中，省略了主语。“表现层"其实指的是"资源”（Resources）的"表现层"。

所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。

所谓"上网"，就是与互联网上一系列的"资源"互动，调用它的URI。

### 表现层（Representation） ###

“资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层”（Representation）。

比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。

URI只代表资源的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。它的具体表现形式，应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对"表现层"的描述。

### 状态转移（State Transfer） ###

访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变化。

互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。而这种转化是建立在表现层之上的，所以就是"表现层状态转化"。

客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

### 统一接口（Uniform Interface） ###

REST 要求，必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以 HTTP/1.1 协议为例，HTTP/1.1 协议定义了一个操作资源的统一接口，主要包括以下内容：

7 个 HTTP 方法：GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

HTTP 头信息（可自定义）

HTTP 响应状态代码（可自定义）

一套标准的内容协商机制

一套标准的缓存机制

一套标准的客户端身份认证机制

REST 还要求，对于资源执行的操作，其操作语义必须由 HTTP 消息体之前的部分完全表达，不能将操作语义封装在 HTTP 消息体内部。这样做是为了提高交互的可见性，以便于通信链的中间组件实现缓存、安全审计等等功能

### 超文本驱动（Hypertext Driven） ###

“超文本驱动”又名“将超媒体作为应用状态的引擎”（Hypermedia As The Engine Of Application State，来自 Fielding 博士论文中的一句话，缩写为 HATEOAS）。将 Web 应用看作是一个由很多状态（应用状态）组成的有限状态机。资源之间通过超链接相互关联，超链接既代表资源之间的关系，也代表可执行的状态迁移。在超媒体之中不仅仅包含数据，还包含了状态迁移的语义。以超媒体作为引擎，驱动 Web 应用的状态迁移。通过超媒体暴露出服务器所提供的资源，服务器提供了哪些资源是在运行时通过解析超媒体发现的，而不是事先定义的。从面向服务的角度看，超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义，而不应该对于是否存在某个 URI 或 URI 的某种特殊构造方式作出假设。一切都有可能变化，只有超媒体的状态迁移语义能够长期保持稳定。

### 综述 ###

综合上面的解释，我们总结一下什么是RESTful架构：

（1）每一个URI代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

### 误区 ###

RESTful架构有一些典型的设计误区。

最常见的一种设计错误，就是URI包含动词。因为"资源"表示一种实体，所以应该是名词，URI不应该有动词，动词应该放在HTTP协议中。

举例来说，某个URI是/posts/show/1，其中show是动词，这个URI就设计错了，正确的写法应该是/posts/1，然后用GET方法表示show。

如果某些动作是HTTP动词表示不了的，你就应该把动作做成一种资源。比如网上汇款，从账户1向账户2汇款500元，错误的URI是：

POST /accounts/1/transfer/500/to/2

正确的写法是把动词transfer改成名词transaction，资源不能是动词，但是可以是一种服务：

POST /transaction HTTP/1.1
    　　Host: 127.0.0.1
    　　
    　　from=1&to=2&amount=500.00

另一个设计误区，就是在URI中加入版本号：

http://www.example.com/app/1.0/foo
    
    　　http://www.example.com/app/1.1/foo
    
    　　http://www.example.com/app/2.0/foo

因为不同的版本，可以理解成同一种资源的不同表现形式，所以应该采用同一个URI。版本号可以在HTTP请求头信息的Accept字段中进行区分（参见Versioning REST Services）：

Accept: vnd.example-com.foo+json; version=1.0
    
    　　Accept: vnd.example-com.foo+json; version=1.1
    
    　　Accept: vnd.example-com.foo+json; version=2.0

[REST_RestfulAPI]: https://www.jianshu.com/p/43dae0b83755
[Roy Thomas Fielding]: https://en.wikipedia.org/wiki/Roy_Fielding
[RESTful API]: http://www.ruanyifeng.com/blog/2014/05/restful_api.html
[https_blog.csdn.net_qq_21383435_article_details_80032375]: https://blog.csdn.net/qq_21383435/article/details/80032375
[http_www.ruanyifeng.com_blog_2011_09_restful.html_bsh_bid_1717507328]: http://www.ruanyifeng.com/blog/2011/09/restful.html?bsh_bid=1717507328