一说到rest 大家都耳熟能详，很多人的第一反应就是其是前后端请求后台的一种通信方式，甚至有些人将REST 和RPC 混为一谈，认为两者都是基于HTTP类似的东西。实际上很少人能叙述REST 所提出的各个约束，风格特点以及如何开始搭建REST服务。
什么是REST
REST（REpresentation State Transfer 表述性状态转移） 描述了一个架构样式的网络系统，他首次出现在Roy Fileding 的博士论文中， 他对此给出了REST API 应该具备的条件：
- REST API 不应该依赖于任何通信协议，尽管是要成功映射到某个协议可能会依赖元数据的可用性，所选的方法等。
- REST API 不应该包含对通信协议的任何改动，除非是补充或确定标准协议中未规定的部分。
- REST API 应该将大部分的描述工作放在定义用于表示资源和驱动应用的媒体类型上，或定义现有标准媒体类型的扩展关系名和（或）支持超文本的标记。
- REST API 绝不应该定义一个固定的资源名或者层次结构（客户端和服务器之间的明显耦合）
- REST API 永远也不应该有那些会影响客户端的“类型化”资源。
- REST API 不应该要求有先验知识，除了初始URI风格和适合目标用户的一组标准化媒体类型。
REST 并非标准，而是一种开发Web应用的架构风格，可以将其理解为一种设计模式。REST 基于HTTP,URI 以及XML 这些 现有的广泛流行的协议和标准，伴随着REST 的应用，HTTP 协议得到了更加正确的使用。
REST有哪些特征
REST指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是REST 。
1. 通过URI来标识资源：系统中的每一个对象都或资源都可以通过一个唯一的URI来进行寻址。URI的结构应该简单，可预测且易于理解，比如定义目录结构式的URI。
2. 统一接口：CRUD操作与HTTP方法之间的一对一映射。比如：
若要在服务器上创建资源应该用 POST 方法
若要检索某个资源应该用 GET 方法
若要更新或添加资源应该用 PUT 方法
若要删除某个资源应该用 DELETE 方法
3. 多重资源表述：URI 所访问的每个资源都可以使用不同的形式加以表示（比如XML 或者JSON）具体的表现形式取决于访问资源的客户端。客户端与服务提供者使用一种协商的机制（请求头与MIME类型）来选择合适的数据格式，最小化彼此之间的数据耦合。
4. 无状态： 对服务器端的请求应该是无状态的，完整，独立的请求不要求服务器在处理请求时检索任何类型的应用程序上下文或状态。
REST API 最佳实践
- 使用名词而不是动词
使用名词来定义接口：
/resources
/resources/1024
不应该使用动词：
/getAllresources
/creatNewResources
/deleteAllresources -
GET 方法查询参数不能改变资源状态
GET /users/111?activave
或
GET /users/111/activate -
使用名词复数
不要混淆名词的单复数。保持简单，只用复数名词来定义所有资源。
/cars 代替 /car
/users 代替 /user
……. -
使用子资源来表达资源间的关系
GET / cars /111/drivers 返回111号car的所有driver 列表
GET /cars /111/drivers/4 返回111号car 的4号列表 -
使用HTTP header 来序列化格式
客户端，服务端都需要知道 相互之间通信的格式。这些格式可以定义在HTTP header 里面。
Content - Type 定义了请求格式。
Accept 定义了接收相应的格式列表 -
使用HATEOAS 约束
HATEOAS 是REST架构风格中最复杂的约束，也是构建成熟REST 服务的核心，它的重要性在与打破了客户端和服务器之间的严格的契约，使客户端可以更加智能和自适应，而REST 服务本身的演化和更新也变得更加容易。 -
提供过滤，排序，字段选择，分页
-
API 版本化：
版本号使用简单的序号，并避免点符号，如1.5 等等， 正确应该为 /blog/api/v1 -
充分使用HTTP 状态码来处理错误。