REST风格的理解

关于REST风格的特点有很多讨论，这里根据归纳一下：

   

1.REST本身不是架构，只是一种架构风格；

2.强调HTTP应当以资源为中心，并且规范了资源URI的风格，只用来定义资源；

3.规范了HTTP请求动作（PUT，POST等）的使用，具有对应的语义；

REST的核心是第一个字母R，即资源（Resource）

REST的核心在于，当设计一个系统的时候，资源是第一位的考虑，首先从资源的角度进行系统的拆分、设计，而不是像以往一样以操作为角度来进行设计

通常系统设计是这样的：

            以新建用户功能为例说明

  为新建用户定义一个URL------>为这个url定义好各个参数------>开始编写前端后后台， 如果要修改用户信息同样需要在定义一个url，  这是以操作为第一位的设计方法，先确认了一个操作，然后围绕这个操作把周边需要的东西设计好，这种方式当然可以架构出一个系统，但是偶尔会有些问题：

1. 操作之间是会有关联，你的设计容易变成“第2个操作要求第1个操作进行过”，这种关系多起来你的系统就乱了
2. 你的URL设计会缺乏一致性
3. 操作通常被认为是有副作用（Side Effect）的，所以很少有人基于操作去设计缓存之类的东西

基于这些问题，可以使用基于资源的角度的方法来设计，基于资源会有一些好处：

1. 各个资源虽然可能有关联，但依旧是能够简单地切掉这些关联导致相互独立的，所以不会有非常乱的耦合性
2. 对资源的操作就这么几种，所以很容易设计一致的URL
3. 对资源的读操作是无副作用的，所以可以使用缓
4. 可提供OpenAPI，便于第三方系统集成，提高互操作性；
5. 如果提供无状态的服务接口，可提高应用的水平扩展性；
   
   

怎么用呢？不同的Server端框架提供了各种解决方案。比如JavaEE中的开箱即用的Spring-MVC。
但实践过程中，你自然会碰到一些需要思考的问题：
1）如何定义资源：一般对应数据库实体（在传统的关系型数据库中）。
2）需要对HTTP协议更多的理解
URL格式：协议://域名/路径?查询#HASH，实际的一个HTTP请求，还会包括Header（含Cookie、Method等）

资源的URI格式：协议://域名/路径，它只是URL的子集，表征一个资源实体。比如， http://a.com/users/1。

恰当地理解和返回Http Status（状态码）。200=成功，404=资源不存在，500=服务器端错误等等。

3）REST操作
一般资源操作只有新增、删除、查询、更新，对应HTTP协议中四类请求：POST、DELETE、GET、PUT。其中，后三个操作是 幂等的。（幂等就是 多次请求的结果和一次请求产生的结果一样）

查询资源时，更多的参数，比如分页、排序、过滤条件，一般都会放在URL的查询部分（Query String）。
新增、更新资源，关于资源实体的内容，一般放在请求体（Request Body）中。

实际发送请求，还需要有动词，表示对该资源执行什么样的操作。 那么超出这个范围的操作该如何扩展？

REST操作返回什么内容？对于删除、新增、更新等操作，通常是返回操作是否成功的标识；如果失败，需要返回错误代码和消息，方便客户端做进一步处理。如果是查询 操作，通常包含实体或者实体列表。
在最佳实践中，应当还应该返回与此操作相关的其他操作。比如，查询得到实体的响应中，应包含该实体的删除、更新操作的地址。

但是也存在缺点

1.因为有了限制，导致设计uri变得复杂了，尤其是复杂的关系，操作，资源集合，硬性套用rest原则设计非常困难。

2.在rest基础上的HATEOAS，返回的json里增加了相应的关系和url。但对复杂的关系和操作，HATEOAS并不能胜任描述。反而在单纯的数据中增加了一堆垃圾信息。

参考： http://www.zhihu.com/question/33959971

REST的核心是第一个字母R，即资源（Resource）

REST的核心在于，当设计一个系统的时候，资源是第一位的考虑，首先从资源的角度进行系统的拆分、设计，而不是像以往一样以操作为角度来进行设计