REST
REST概述
简介
REST是英文Resource Representational State Transfer的缩写，翻译为资源在网络中以某种表现形式进行状态转移。
- Resource：资源，即数据（网络的核心）。比如 newsfeed，friends等；
- Representational：某种表现形式，比如用JSON，XML，JPEG等；
- State Transfer：状态变化，通过HTTP动词实现。
Rest原则
- 网络上的所有事物都可以被抽象为资源。
- 每一个资源都有唯一的资源标识,对资源的操作不会改变这些标识。
- 所有的操作都是无状态的。
设计思想
REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源（包括网络资源）只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。
我们可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过HTTP规范定义的，其核心操作只有GET，POST，PUT，DELETE。也就是：
URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。
因此设计web接口的时候，REST主要是用于定义接口名，接口名一般是用名词写，不用动词，那怎么表达“获取”后者“删除”这样的操作呢——用请求类型（GET，PUT，POST，DELETE）来区分。
案例
比如我们设计一个用户管理系统的接口，如果不使用Restful风格，接口会定义如下：
http://127.0.0.1/user/query/1 #根据用户id查询用户数据 GET请求
http://127.0.0.1/user/adduser #新增用户 Post请求
http://127.0.0.1/user/update #修改用户信息 PUT请求
http://127.0.0.1/user/delete #删除用户信息 DELETE请求
从上面的定义接口来看貌似没什么问题，但是仔细揣测就会发现有一些瑕疵：比如查询方法定义接口使用了query动词，而GET请求本身的含义也就是从服务器获取资源，带有查询的含义，如果接口里面定义又加上这样的动词显得重复，同理其他几个接口也是一样的。
而使用Rest接口定义如下：
http://127.0.0.1/user/1 #GET 根据用户id查询用户数据
http://127.0.0.1/user #POST 新增用户
http://127.0.0.1/user #PUT 修改用户信息
http://127.0.0.1/user #DELETE 删除用户信息
从上面定义的接口可以看出，接口名称主要指向user资源，具体的资源操作（增删改查）由HTTP的请求类型来定义。这样接口名称显得统一整洁，就不用定义不同的接口名称。遵循这样一种风格的Rest接口就叫做Restful。
HTTP方法幂等性与安全性
| HTTP方法 | 资源操作 | 幂等 | 安全 |
|---|---|---|---|
| GET | SELECT | 是 | 安全 |
| POST | INSERT | 否 | 否 |
| PUT | UPDATE | 是 | 否 |
| DELETE | DELETE | 是 | 否 |
- 幂等：对同一REST接口多次请求，得到的资源状态是相同的。
- 安全：对该Rest接口请求，不会使服务器资源发生改变。
REST优势
由于REST强制所有操作都必须是无状态的，这就没有上下文约束，如果做分布式，集群都不需要考虑上下文和回话保持的问题，极大的提高系统的可伸缩性。
前后端分理，前端拿到的数据只负责展示和渲染，不对数据做任何处理。后端处理数据并以JSON格式传输出去，定义这样一套统一的接口，在web, ios, android三段都可以用相同的接口。
