1、Restful的由来
全称：Restful的全称为Resource Representational State Transfer，即：资源在网络中以某种形式进行状态转移。
定义：简单来说，Restful系统架构设计风格（而非标准），一种分布式系统的应用层解决方案。
2、Restful的特征和优点
（1）客户端-服务器（Client-Server）：提供服务的服务器和使用服务的客户端分离解耦；
优点：提高客户端的便捷性（操作简单）
简化服务器，提高可伸缩性（高性能、低成本）
允许客户端与服务器分组优化，彼此不受影响
（2）无状态（Stateless）：来自客户的每一个请求必须包含服务器处理该请求所需的所有信息（请求信息唯一性）；
优点：提高可见性（可以单独考虑每个请求）
提高可靠性（更容易故障恢复）
提高了可拓展性（降低服务器资源的使用）
（3）可缓存（Cachable）：服务器必须让客户端知道请求是否可以被缓存？如果可以，客户端可以重用之前的请求信息发送请求；
优点：减少交互连接数
减少连接过程中的网络延迟
（4）分层系统（Layered System）：允许服务器和客户端之间的中间层（代理，网关等）代替服务器对客户端的请求进行回应，而客户端不需要关心与它交互的组件之外的事情；
优点：提高了系统的可拓展性
简化了系统的复杂性
（5）统一接口（Uniform Interface）：客户端与服务器之间通信的方法必须是统一化的（例如：GET，POST，PUT，DELETE）
优点：提高交互的可见性
鼓励单独优化改善组件
（6）支持按需代码（Code-On-Demand,可选）：服务器课可以提供一些代码或者是一些脚本在客户端运行环境中执行
优点：提高可拓展性
3、概要设计方法
（1）协议
API与Client的通信协议，总是使用HTTPS协议。
PS：使用HTTPS协议和Restful API本身没有多大关系，但是对于增加网站的安全性非常重要，特别是如果提供的是公开的API，那么HTTPS就更加重要。
（2）域名
应该尽量将API部署在专用的域名下，例如：
https://example.com
如果API变化较大，可以把API设计成子域名，比如：
https://example.com/api/v1
（3）版本
一般而言应该将API放入URL中，例如：
https://example.com/api/v1
当然，还可以把版本号放入HTTP信息头，但这样不如放入URL方便直观
（4）路径
在协议中，每个网站代表一种资源的存放地址，所以网站中不能有动词，只能有名词，而且名词一般都应该与数据库中的表字段相对应，且API中的名词应该使用复数。例如：
/users/:username/repos /users/:org/repos /repos/:owner/:repo /repos/:owner/:repo/tags /repos/:owner/:repo/branches/:branch
（5）方法
有了资源的URL设计，所有针对资源的操作都是使用HTTP方法指定的，常见的方法有（括号中对应的是SQL命令）
HEAD（SELECT）：获取某个资源的头部信息
GET（SELECT）：获取资源
POST（CREATE）：创建资源
PATCH（UPDATE）：更新资源的部分属性（很少用，一般用POST代替）
PUT（UPDATE）：更新资源，客户端需要提供新建资源的所有属性
DELETE（DELETE）：删除资源
（6）数据过滤
如果数据量太大，服务器不可能将所有数据返回给用户。API应该提供参数（比如 QUERY），过滤返回结果。例如：
?limit=10：指定返回记录的数量 ?offset=10：指定返回记录的开始位置 ?page=2&per_page=100：指定第几页，以及每页的记录数 ?sortby=name&order=asc：指定返回结果按照哪个属性排序，以及排序顺序 ?state=close：指定筛选条件
（7）状态码
在HTTP报文构成中，status code很重要。他说明了请求的大致情况，是否正常处理，出现了什么错误等。状态码都是三位数，大概分为了一下几个区间：
2XX：请求正常处理并返回
3XX：重定向，请求资源的位置发生变化
4XX：客户端发送的请求有误
5XX：服务器端的错误