一种软件的架构风格，设计风格，而不是标准，为客户端和服务端的交互提供一组设计原则和约束条件。
一 面向资源编程
每个URL代表一种资源，URL中尽量不要用动词，要用名词，往往名词跟数据库表格相对应。
二 根据method不同，进行不同的操作
GET/POST/PUT/DELETE/PATCH
三 在URL中体现版本
https://www.bootcss.com/v1/mycss
https://v1.bootcss.com/mycss
四 在URL中体现是否是API
https://www.bootcss.com/api/mycss
https://api.bootcss.com/mycss
五 在URL中的过滤条件
https://www.bootcss.com/v1/mycss？page=3
六 尽量使用HTTPS
https://www.bootcss.com/v1/mycss
七 响应时设置状态码
1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误
八 返回值
GET请求 返回查到所有或单条数据
POST请求 返回新增的数据
PUT请求 返回更新数据
PATCH请求 局部更新 返回更新整条数据
DELETE请求 返回值为空
九 返回错误信息
返回值携带错误信息
十 Hypermedia API
如果遇到需要跳转的情况 携带调转接口的URL
ret = {
code: 1000,
data:{
id:1,
name:'小强',
depart_id:http://www.luffycity.com/api/v1/depart/8/
}
}
下面六条准则定义了一个 REST 系统的特征： 1.客户-服务器（Client-Server），提供服务的服务器和使用服务的客户需要被隔离对待。 2.无状态（Stateless），来自客户的每一个请求必须包含服务器处理该请求所需的所有信息。换句话说，服务器端不能存储来自某个客户的某个请求中的信息，并在该客户的其他请求中使用。
3.可缓存（Cachable），服务器必须让客户知道请求是否可以被缓存。（Ross：更详细解释请参考 理解本真的REST架构风格 以及 StackOverflow 的这个问题 中对缓存的解释。） 4.分层系统（Layered System），服务器和客户之间的通信必须被这样标准化：允许服务器和客户之间的中间层（Ross：代理，网关等）可以代替服务器对客户的请求进行回应，而且这些对客户来说不需要特别支持。 5.统一接口（Uniform Interface），客户和服务器之间通信的方法必须是统一化的。（Ross：GET,POST,PUT.DELETE, etc） 6.支持按需代码（Code-On-Demand，可选），服务器可以提供一些代码或者脚本（Ross：Javascrpt，flash，etc）并在客户的运行环境中执行。这条准则是这些准则中唯一不必必须满足的一条。
（Ross：比如客户可以在客户端下载脚本生成密码访问服务器。）