Rest与RestFul
1.Rest是什么
Roy Thomas Fielding博士是HTTP和URI等Web架构标准的主要设计者，Apache HTTP服务器的主要开发者。他在他的博士论文里提出了“架构风格”这个软件领域的专业术语，推导出一个称为“REST”的架构风格，并详细阐述了REST架构风格的推倒过程，指出不同架构的评价标准就是其背后的的架构风格。值得注意的是，REST指的是一种架构风格的名称，这里的风格，不同于我们通常所说的个性化的含义，它代表的一组特征，在软件领域我们把它叫做架构约束。
2.Rest与RestFul的关系
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
3.使用Rest的好处
(1). 轻量，直接基于http，不再需要任何别的诸如消息协议。get/post/put/delete为CRUD操作
(2). 面向资源，一目了然，具有自解释性。
(3). 数据描述简单，一般以xml，json做数据交换。
(4). 无状态，在调用一个接口（访问、操作资源）的时候，可以不用考虑上下文，不用考虑当前状态，极大的降低了复杂度。
(5). 简单、低耦合
4.Rest的弊端
缺点是因为这种限制，导致设计uri变得复杂了。尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。这也同样带来问题。好处是对简单的关系，的确可以通过url进一步处理。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。
5.RestFul设计原则
(1) 在接口命名时应该用名词，不应该用动词，因为通过接口操作到是资源。
(2) 在url中加入版本号，利于版本迭代管理更加直观
https://www.rgc.com/v1/
(3) 对于资源的操作类型应该是通过http动词表示。
GET /zoos：列出所有动物园
POST /zoos：新建一个动物园
GET /zoos/ID：获取某个指定动物园的信息
PUT /zoos/ID：更新某个指定动物园的信息（提供该动物园的全部信息）
DELETE /zoos/ID：删除某个动物园
GET /zoos/ID/animals：列出某个指定动物园的所有动物
DELETE /zoos/ID/animals/ID：删除某个指定动物园的指定动物
(4) 排序规则：默认时升序，‘-’为降序;多个排序规则时以逗号间隔组合。使用sort查询参数限制
GET /tickets?sort=-time,created_at
优先以time倒序显示，其次以created_at正序显示
(5) 限制返回值的字段域：明确指定输出字段列表，用于控制网络带宽和速度。使用fields查询参数来限制。
GET /tickets?fileds=id,subject,customer_name,time&sort=-time
返回参数列表为id,subject,customer_name,time，并且以time字段倒序显
(6) HTTP Method分别对于资源的CURD操作
GET（SELECT）：从服务器取出资源（一项或多项）。
POST（CREATE）：在服务器新建一个资源。
PUT（UPDATE）：在服务器更新资源（客户端提供改变后的完整资源）。
PATCH（UPDATE）：在服务器更新资源（客户端提供改变的属性）。
DELETE（DELETE）：从服务器删除资源。
保证 POST，PUT，DELETE,PATCH操作幂等性。
(7) 使用SSL(Secure Sockets Layer 安全套接层)
(8) 参数和url采用蛇行命名方式。如：updated_time
(9) 服务器请求和返回的数据格式，应该尽量使用JSON，避免使用XML。在 request中的Accept和Response中的Content-Type:application/json
6.REST 系统的特征
客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。
无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。
可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。（Ross：更详细解释请参考 理解本真的REST架构风格 以及 StackOverflow 的这个问题 中对缓存的解释。）
分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。
统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。（Ross：GET,POST,PUT.DELETE, etc）
支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本（Ross：Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。（Ross：比如客户可以在客户端下载脚本生成密码访问服务器。）
7.SOAP、RestFul 、HATEOAS
SOAP 是简单对象访问协议,是基于xml以及多种协议(http smtp mime),使用ws-security来进行安全控制
RESTFUL Web API是使用HTTP并遵循REST原则的Web服务,URI 可以完成资源定位，GET、POST、OPTION等方法可以完成资源操作
HATEOAS（Hypermedia as the engine of application state）是 REST 架构风格中最复杂的约束，也是构建成熟 REST 服务的核心。它的重要性在于打破了客户端和服务器之间严格的契约，使得客户端可以更加智能和自适应，而 REST 服务本身的演化和更新也变得更加容易。
