概述：
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
原文地址：https://www.cnblogs.com/ydc198/p/10667181.html