为什么需要RESTful
对于http接口的调用，其历程经历过原始servlet，到后面的struts，SpringMVC，对于后端的参数封装也逐渐从单个属性演变成对象封装，然而即使到现在，我们对于http接口的封装，仍有不少公司采用下述示例：
在这种模式下，开发人员一般将功能（或页面）聚合成一个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
资源
GET
PUT
POST
DELETE
一组资源的URI，比如http://example.com/resources/
列出URI，以及该资源组中每个资源的详细信息（后者可选）
使用给定的一组资源替换当前整组资源
在本组资源中创建/追加一个新的资源。该操作往往返回新资源的URL
删除整组资源
单个资源的URI，比如http://example.com/resources/142
获取指定的资源的详细信息，格式可以自选一个合适的网络媒体类型（比如：XML、JSON等）
替换/创建指定的资源。并将其追加到相应的资源组中。
把指定的资源当做一个资源组，并在其下创建/追加一个新的元素，使其隶属于当前资源。
删除指定资源
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做到的也就是这个级别。
