RESTful levels、HATEOAS

概述：　　

　　REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。它首次出现在 2000 年 Roy Fielding 的博士论文中，Roy Fielding是 HTTP 规范的主要编写者之一。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。

原则条件：

　　REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

　　RESTful的实现：

RESTful Web 服务的 Java 框架；

RESTful Web 服务与 RPC 样式的 Web 服务；构建 RESTful Web 服务的多层架构。

RESTful 的成熟度模型：

Level 0

利用 HTTP 协议做数据交换，所有的参数描述通过 url 或者 POST body 形式通知服务器，返回相应的数据，此级别通常都是基于。实质上就是基于 HTTP 的 RPC（远程过程调用），具体交付的细节完全由相关规范或团队内部约定解决。

Level 1

将 API 按照 RESTful 中资源的方式进行划分，初步有了自我描述（self description）的特性了，客户端可以对相关的资源进行更加细致的操作。

Level 2

这个级别有更加进一步的利用了 HTTP 的特性，增加了对 HTTP verb （比如 GET 表示查询、POST 表示创建、PUT 表示修改、DELETE 表示等等）的运用，并且运用原有的 HTTP response status 来表征业务上请求的成功与失败，一般项目常见的 RESTful 运用基本都接近这个级别。

Level 3

这个基本也称作 HATEOAS (Hypertext As The Engine Of Application State)，这个级别是 RESTful 最复杂的实现，这个级别最理想的情况是，不需要特别复杂 API 文档进行描述的，这里的 API 设计最大化的实现了 RESTful 的自我描述特性。这种方案虽然引入很大的复杂性，但是最大限度的将 API 设计变得配置化了，所有 API 设计将会基于更加抽象的工作流设计了。

-------------------------

转自：https://www.jianshu.com/p/f264db28bce1

什么是HATOEAS：

　　HATEOAS是 Hypertext As The Engine Of Application State 的缩写。采用Hypermedia的API在响应（response）中除了返回资源（resource）本身外，还会额外返回一组Link。这组Link描述了对于该资源，消费者（consumer）接下来可以做什么以及怎么做。

举例来说，假设向API发起一次get请求，获取指定订单的资源表述（representation）：

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/hal+json;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 05 Jun 2015 02:54:57 GMT

{
    "tracking_id": "123456",
    "status": "WAIT_PAYMENT",
    "items": [
        {
            "name": "potato",
            "quantity": 1
        }
    ],
    "_Links": {
        "self": {
            "href": "http://localhost:57900/orders/123456"
        },
        "cancel": {
            "href": "http://localhost:57900/orders/123456"
        },
        "payment": {
            "href": "http://localhost:57900/orders/123456/payments"
        }
    }
}

理解Link中的“self”的消费者知道使用get方法访问其“href”的uri可以查看该订单的详细信息
理解Link中的“cancel”的消费者知道使用delete方法访问其“href”的uri可以取消该订单
理解Link中的“payment”的消费者知道使用post方法访问其“href”的uri可以为该订单付款

　　HATEOAS提倡在响应返回Link来提示对该资源接下来的操作。这种方式解耦了服务端URI，也可以让客户端开发者更容易地探索API。最后，通过Link来判断业务状态，还能有效地消除单页应用中的业务规则重复实现。

-----------------------------

转自：https://www.colabug.com/3967837.html