为什么需要RESTful

对于http接口的调用，其历程经历过原始servlet，到后面的struts，SpringMVC，对于后端的参数封装也逐渐从单个属性演变成对象封装，然而即使到现在，我们对于http接口的封装，仍有不少公司采用下述示例：

@ApiOperation("执行")
@PostMapping("/execute")
publicResult<Void>execute(@Valid@RequestBodyExecuteRequestrequest) {
// 业务逻辑处理...returnResult.success();
}

在这种模式下，开发人员一般将功能（或页面）聚合成一个controller，接口的路径定义也具备行为的特征，如对订单的操作，接口的定义一般形似（如删除、ID查询也可DELETE/GET）：

在这种模式下我们对于订单协议的封装存在一个明显的问题：订单这个资源其行为是不规范的，同样是删除，有的人员定义为POST请求，有的是GET请求，资源表现的行为没有一个统一标准。更有甚者甚至会将order的功能封装成多个路径：save/order、save/product，这对于后续协议的维护简直就是灾难级别。因此我们需要一种设计规范，将程序员对于同一资源的行为封装做到规范统一。

总结为RESTful风格的设计拥有以下特点：结构清晰、统一标准、易于理解、扩展方便。

什么是RESTful

Resource Representational State Transfer：资源具象状态传输

RESTful是一个理念，是一个设计规范，而并非什么协议，其主要关键词如下：

资源

在RESTful的理念下，互联网中任意信息都可定义为资源，如上述对于订单的增删改查，在此就抽象为订单资源；资源会对应一个特定的URI，URI为每一个资源的地址或独一无二的标识符，对应订单就可抽象为：http://application/order。此时订单抽象为资源，资源对应唯一的URI，后续对此资源的操作都将遵循此URI。

表现层

针对资源对外输出的展现，这种呈现形式称之为表现层。以为本为例可以对外呈现为：json/xml/html等多种格式。

状态转化

客户端通过访问服务端，进行增删改查操作，从而对资源状态产生变化，这个过程便是：资源的状态转化。以http协议为例（RESTful不仅使用HTTP协议，只不过是经常以HTTP协议为衬托），客户端可通过一些操作让服务端的资源进行变化。整个过程即为：表现层状态转化。而HTTP协议中常见操作方式：GET/POST/PUT/DELETE

如何使用RESTful

RESTful使用进阶

上面对于RESTful的理解和使用我们有了一个认知，但是如果不能在涉及之初就对资源进行合理的划分，RESTful将变成只是针对现有功能的包路径调整。因此我们最好可以在设计之初就引入对应的资源概念。

1.架构中引入资源（Resource）的概念

最常见的错误就是在URI中包含动词，比如URI=http://example.com/getOrder?orderId=1234，其实「资源」表示一种实体，所以应该是名词，动词应该放在HTTP协议中。而与此同时URI也有可能破坏HTTP GET的安全性和幕等性，比如某个客户端在http://example.com/updateOrder?id=1234&coffee=latte上执行GET（而不是POST），就能创建一笔新的咖啡订单（一个资源），按理来说GET请求不能改变服务的任何状态。

2.每一个URI代表一种资源，支持HTTP动词

此时使用多个URI的话，需要让不同的URI代表不同的资源（多个URI可能指向同一个Resource，而一个URI不能指向不同Resource），同时使用多个HTTP方法操作这些资源，例如使用POST/GET/PUT/DELET分别进行CRUD操作。这时候HTTP头和有效载荷都包含业务逻辑，例如HTTP方法对应CRUD操作，HTTP状态码对应操作结果的状态。我们现在看到的大多数所谓RESTful API做到的也就是这个级别。