Restful

Restful架构风格的服务是围绕资源展开的，是典型的ROA架构。

REST指的是一组架构约束条件和原则，如果一个架构符合REST的的约束条件和原则，我们就称它为Restful架构。REST中最重要的抽象概念就是资源。

资源与URI：
资源可以是一个实体(例如手机号)，也可以只是一个抽象的概念(例如价值)，要让一个资源可以被识别，就需要有一个唯一的标识，在web中这个唯一的标识就是URI，URI既可以看做是资源的地址，也可以看做是资源的名称，如果某些信息没有使用URI来表示，那它就不能算是一个资源。URI的设计应该遵循可寻址性的原则，就是说在形式上能一眼就看出来它是干什么的。

URI的设计技巧：
1：使用_或-让URI的可读性更好。如：http://www.baidu.com/news/get-news-info
2：使用/来表示资源的层级关系。如：/orders/2012/10可以用来表示2012年10月的订单记录。
3：使用?来过滤资源。如：/git/git/pulls用来表示git项目的所有推入请求，而/git/git/pulls?state=closed可以用来表示项目中已经关闭的推入请求。

规则：
GET 用来获取资源
POST 用来新建资源(也可以用于更新资源)
PUT 用来更新资源
DELETE 用来删除资源

概念：REST是面向资源的，而资源是通过URI进行暴露的。URI的设计只要负责把资源通过合理的方式暴露出来就可以了，对资源的操作与uri没有关系，操作是通过HTTP的动词来体现，所以REST通过URI暴露资源时，会强调不要在URI中出现动词。
比如：左边是错误的设计，而右边是正确的：

GET /rest/api/getDogs --> GET /rest/api/dogs 获取所有小狗狗 
GET /rest/api/addDogs --> POST /rest/api/dogs 添加一个小狗狗 
GET /rest/api/editDogs/:dog_id --> PUT /rest/api/dogs/:dog_id 修改一个小狗狗 
GET /rest/api/deleteDogs/:dog_id --> DELETE /rest/api/dogs/:dog_id 删除一个小狗狗

REST很好地利用了HTTP本身就有的一些特征，如HTTP动词、HTTP状态码、HTTP报头等等

其实简单的说Restful就是用URI定位资源，用http描述操作。在设计接口的时候REST主要是用于定义接口名，接口名一般是用名词表示，不用动词。那么怎么表达获取、删除、更新的操作呢？在REST中，这些操作是用类型来区分。
比如，我们有一个friends接口，对于朋友，我们有增删改查四种操作，怎么定义REST接口？
增加一个朋友，uri：/v1/friends 接口类型：POST
删除一个朋友，uri：/v1/friends 接口类型：DELETE
修改一个朋友，uri：/v1/friends 接口类型：PUT
查找一个朋友，uri：/v1/friends 接口类型：GET

向这样的接口就是符合REST协议的，这些接口都没有动词，只有名词friends，都是通过http请求的接口类型来判断是什么业务操作。如：/v1/deleteFriends该接口用来表示删除朋友，这样的接口就不符合REST协议。

一般接口的返回值是JSON或者XML。很多不规范的接口都是自己定义一个code来表示此次的请求是否成功，比如code=200表示成功，code=0表示失败，但这带来的一个问题就是需要与前端协商code的值代表的含义，如果我们这套接口需要与web、ios、android进行交互，就需要分别与三端的开发人员进行协商，及其不方便。

我们可以用HTTP的status来传递server的状态信息，比如最常用的200表示成功，500表示server内部错误，403表示Bad Request等等。这种风格的接口带来的好处就是前后端分离，web、ios、android三端都可以用相同的接口。

Restful API的优缺点：
优点：
1.适合开放性高的API。这几年的由于移动互联网流行使得前端设备多样化，业界急需一种统一的机制来规范API设计，使得API适用于各种各样的前端设备，REST符合这种需求。
2.行为和资源分离，更容易理解。
3.提出使用版本号（例如v1、v2），更加规范。

缺点：
1.对后端开发人员要求高，业务逻辑有时难以被抽象为资源的增删改查。
2.对前端开发人员不友好，API粒度较粗，难以查询符合特殊要求的数据，同样的业务要比普通的API需要更多次HTTP请求。

应用状态与资源状态：
实际上，状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。客户端与服务端的交换必须是无状态的，并在每一次的请求中包含处理该请求所需的一切信息，服务端不需要在请求间保留应用的状态，只有在接收到实际的请求时，服务端才会关注应用的状态，这种无状态的通信原则，使得服务端和中介能够理解独立的请求和响应。就意味着，在多次请求中，统一客户端也不再需要依赖于同一服务器，能方便的实现高可扩展和高可用性的服务端。