REST原则六约束与Richardson成熟度模型

2019独角兽企业重金招聘Python工程师标准>>>

1. 前言

REST即Representational State Transfer，表述状态转移。这里Representational被翻译成表述或表征，其含义在网络上存在各种模糊的解释。

从本意上来说“presentational”是有“表象”的含义的，加上“re”之后，表示一种可重复的表象的含义，依然觉得很抽象！！！

 

在wiki百科上有一段关于的Figurative art（具象艺术）的定义，看了这个之后，我觉得可以窥探其中的含义。

Figurative art, sometimes written as figurativism, describes artwork—particularly paintings and sculptures—that is clearly derived from real object sources, and are therefore by definition representational.（https://en.wikipedia.org/wiki/Figurative_art）

具象艺术，有时被写成具象主义，它所描述的艺术品——尤其是绘画和雕塑——是由真实对象派生而来的，它是通过表征定义的。

由此可知，表征指的就是一种描述方式，它准确定义了真实存在的事物，在具象艺术里，我们通过绘画和雕塑来定义真实的物体。

那么，这种描述就是一种表征，它可以被用来定义真实存在的事物，是一种“可重复的表像”，因为其被记录了下来。

（另外需要说明一下，具象艺术与抽象艺术，像《蒙娜丽莎的微笑》就是基本真实记录了人物（严格来说，也存在比例优化美化后的失真），而抽象技术，毕加索的算是吧！）

 

那么在我们所说的Representational State Transfer中，它指的是什么呢？

在计算机领域“Representational”表述或表征的对象是一种资源，这里的资源具体一点可以指图片，视频，数据库中的字段等等，

那么这种表述或表征就是定义这些资源的方式，说道这里恍然大悟，那具体一点，不就是JSON，XML这些描述资源的东西吗！

确实如此，“Representational”是个大的概念，它包括一切的这些JSON，XML的子集。感叹一下，REST作者的用词很是准确。

 

2. REST原则六约束
（1）Client–server 客户端-服务器模式
通信只能由客户端单方面发起，表现为请求-响应的形式。

（2）Stateless 无状态
通信的会话状态（Session State）应该全部由客户端负责维护。

（3）Cacheable 可缓存
响应内容可以在通信链的某处被缓存，以改善网络效率。

（4）Layered system 分层系统
通过限制组件的行为（即，每个组件只能“看到”与其交互的紧邻层），将架构分解为若干等级的层。

（5）Code on demand (optional) 按需扩展代码（可选）
支持通过下载并执行一些代码（例如Java Applet、Flash或JavaScript），对客户端的功能进行扩展。

（6）Uniform interface 统一接口
通信链的组件之间通过统一的接口相互通信，以提高交互的可见性。

        1）资源标识的唯一性（资源的标识） Identification of resources

            每个资源的资源标识可以用来唯一地标明该资源。
            请求中的独立资源是可以被标识的，基于web的REST系统使用的URI就是典型的例子。资源在概念上是独立的，并由表述返回客户端。举例来说，服务器把数据库中的数据以HTML，XML 或者 JSON发送给客户端，而这些表述不是在服务中内置的。

        2）资源的自描述性（通过表述对资源执行的操作）Manipulation of resources through these representations

            一个REST系统所返回的资源需要能够描述自身，并提供足够的用于操作该资源的信息，如如何对资源进行添加，删除以及修改等操作。也就是说，一个典型的REST服务不需要额外的文档对如何操作资源进行说明。
            当客户端抓取一个资源表述的时候，它都可以通过充足的信息来保证对资源的修改或者删除。

        3）消息的自描述性（自描述消息）Self-descriptive messages

            在REST系统中所传递的消息需要能够提供自身如何被处理的足够信息。例如该消息所使用的MIME类型，是否可以被缓存等。

        4）超媒体驱动性（超媒体作为应用状态的引擎）Hypermedia as the engine of application state

             即客户只可以通过服务端所返回各结果中所包含的信息来得到下一步操作所需要的信息，如：到底是向哪个URL发送请求等。也就是说，一个典型的REST服务不需要额外的文档标示通过哪些URL访问特定类型的资源，而是通过服务端返回的响应来标示到底能在该资源上执行什么样的操作。
             一个REST服务的客户端也不需要知道任何有关哪里有什么样的资源这种信息。当客户端抓取一个资源表述的时候，它都可以通过充足的信息来保证对资源的修改或者删除。

 

3. Richardson的REST成熟度模型

一个WEB服务有多么的“RESTful”，最有名的就是《RESTful Web Services》的合著者Leonard Richardson提出的REST成熟度模型，简称 Richardson成熟度模型！

第0级：使用HTTP作为传输方式；一个URI，一个HTTP方法
SOAP、XML-RPM都属于这一级别，仅是来回传送"Plain Old XML"(POX)。即使没有显式调用RPC接口（SOAP、XML-RPM），通常会调用服务器端的一个处理过程。一个接口会有一个端点，文档的内容会被解析用还判断所要调用的处理过程及其参数。这种做法相当于把 HTTP 这个应用层协议降级为传输层协议用。HTTP 头和有效载荷是完全隔离的，HTTP 头只用于保证传输，不涉及业务逻辑；有效载荷包含全部业务逻辑，因此 API 可以无视 HTTP 头中的任何信息。

 

第1级：引入了资源的概念，每个资源有对应的标识符和表达；多个URI，一个HTTP方法
这些资源仍是被“GETful”接口操作而不是HTTP动词，服务基本上只提供操作这些资源。例如：
GET http://example.com/app/createUser
GET http://example.com/app/getUser?id=123
GET http://example.com/app/changeUser?id=123&field=value
GET http://example.com/app/deleteUser?id=123

 

第2级：根据语义使用HTTP动词，适当处理HTTP响应状态码；多个URI，多个HTTP方法
在这一级别，资源名称为基URI的一部分，而不是查询参数。
GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。
HEAD：获取资源的元数据。
OPTIONS：获取信息，关于资源的哪些属性是客户端可以改变的。

 

第3级：使用超媒体作为应用状态引擎（HATEOAS）；多个URI，多个HTTP方法
特别注意，这里是超媒体（hypermedia），超媒体概念是包括超文本的。
我们已经知道什么是多媒体（multimedia），以及什么是超文本（hypertext）。其中超文本特有的优势是拥有超链接（hyperlink）。如果我们把超链接引入到多媒体当中去，那就得到了超媒体，因此关键角色还是超链接。使用超媒体作为应用引擎状态，意思是应用引擎的状态变更由客户端访问不同的超媒体资源驱动。

具体例子么？
你可以想象一下在游戏中，你的角色移动，攻击的过程，触发都是状态的变更！而实际的应用，我们只能降级了（超文本是超媒体的一个子集），在返回的JSON中应该是带有超链接的。
Roy Fielding（REST论文的作者）说”只有使用了超媒体的才能算是 REST！”那么——第 3 级成熟度以外的都不算 REST！！！

 

其实细想一下，你就会发现很多系统宣称自己按照REST构建的API不过达到了第1级或第2级成熟度。

4. 实施案例

 http://my.oschina.net/crooner/blog/644831

 

 转载请保留源地址：http://my.oschina.net/crooner/blog/644825

 

转载于:https://my.oschina.net/crooner/blog/644825