RESTful发展背景及简介
网络应用程序，分为前端和后端两个部分。当前的发展趋势，就是前端设备层出不穷（手机、平板、桌面电脑、其他专用设备…）。因此，必须有一种统一的机制，方便不同的前端设备与后端进行通信。这导致API构架的流行，甚至出现"APIFirst"的设计思想。RESTful API是目前比较成熟的一套互联网应用程序的API设计理论。
REST（Representational State Transfer）表述性状态转换，REST指的是一组架构约束条件和原则。 如果一个架构符合REST的约束条件和原则，我们就称它为RESTful架构。REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。
RESTful API设计
资源路径
对于rest资源的定义，即URL的定义，是最重要的；想要设计出优雅的、易读的rest 接口，其实还是听不容易的。
URL中不能有动词
在Restful架构中，每个网址代表的是一种资源，所以网址中不能有动词，只能有名词，动词由HTTP的 get、post、put、delete 四种方法来表示。
URL结尾不应该包含斜杠“/”
这是作为URL路径中处理中最重要的规则之一，正斜杠（/）不会增加语义值，且可能导致混淆。REST API不允许一个尾部的斜杠，不应该将它们包含在提供给客户端的链接的结尾处。
许多Web组件和框架将平等对待以下两个URI：
但是，实际上URI中的每个字符都会计入资源的唯一身份的识别中。
两个不同的URI映射到两个不同的资源。如果URI不同，那么资源也是如此，反之亦然。因此，REST API必须生成和传递精确的URI，不能容忍任何的客户端尝试不精确的资源定位。
有些API碰到这种情况，可能设计为让客户端重定向到相应没有尾斜杠的URI（也有可能会返回301 - 用来资源重定向）。
正斜杠分隔符”/“必须用来指示层级关系
rul的路径中的正斜杠“/“字符用于指示资源之间的层次关系。
例如：
http://api.user.com/schools/grades/classes/boys
- 学校中所有的男生
http://api.college.com/students/3248234/courses
- 检索id为3248234的学生学习的所有课程的清单。
应该使用连字符”-“来提高URL的可读性，而不是使用下划线”_”
为了使URL容易让人们理解，请使用连字符”-“字符来提高长路径中名称的可读性。
一些文本查看器为了区分强调URI，常常会在URI下加上下划线。这样下划线”_”字符可能被文本查看器中默认的下划线部分地遮蔽或完全隐藏。
为避免这种混淆，请使用连字符”-“而不是下划线
URL路径中首选小写字母
RFC 3986将URI定义为区分大小写，但scheme 和 host components除外。
URL路径名词均为复数
为了保证url格式的一致性，建议使用复数形式。
RESTful API对资源的操作
对于rest api资源的操作，由HTTP动词表示
CURD操作
GET: 获取资源
POST： 新建资源
PUT：在服务器更新资源（向客户端提供改变后的所有资源）
PATCH: 在服务器更新资源（向客户端提供改变的属性）
DELETE：删除资源
PATCH
一般不用，用 PUT
资源过滤
在获取资源的时候，有可能需要获取某些“过滤”后的资源，例如指定前10行数据
http://api.user.com/schools/grades/classes/boys?page=1&page-size=10
返回状态码推荐标准HTTP状态码
有很多服务器将返回状态码一直设为200，然后在返回body里面自定义一些状态码来表示服务器返回结果的状态码。由于rest api是直接使用的HTTP协议，所以它的状态码也要尽量使用HTTP协议的状态码。
200 OK 服务器返回用户请求的数据，该操作是幂等的
201 CREATED 新建或者修改数据成功
204 NOT CONTENT 删除数据成功
400 BAD REQUEST 用户发出的请求有问题，该操作是幂等的
401 Unauthoried 表示用户没有认证，无法进行操作
403 Forbidden 用户访问是被禁止的
422 Unprocesable Entity 当创建一个对象时，发生一个验证错误
500 INTERNAL SERVER ERROR 服务器内部错误，用户将无法判断发出的请求是否成功
503 Service Unavailable 服务不可用状态，多半是因为服务器问题，例如CPU占用率大，等等
状态码 使用场景
400 bad request 常用在参数校验
401 unauthorized 未经验证的用户，常见于未登录。如果经过验证后依然没权限，应该 403（即 authentication 和 authorization 的区别）。
403 forbidden 无权限
404 not found 资源不存在
500 internal server error 非业务类异常
503 service unavaliable 由容器抛出，自己的代码不要抛这个异常
============================================================
接口
接口：连接两个物质的媒介，完成信息交互。而web程序中的接口：作为前台页面与后台数据库连接的媒介。
web接口组成：
url：长得像放回数据的url链接。如api.baidu.map/search，一访问后台返回给你的是一大堆查询到的数据 结果 。作为接口最主要的部分。
请求参数：前台按照指定的key提供数据给后台
响应数据：后台与数据库交互后将数据反馈给前台
一个规定的请求参数的url访问后能返回对应的结果的url链接。
restful接口规范
接口规范：就是为了采用不同的后台语言，也能使用同样的接口获取到同样的数据。
如何写接口：接口规范是规范化书写接口的，写接口要写 url、响应数据。
注意：如果将请求参数也纳入考量范围，那就是在写 接口文档
url
1）用api关键字来标识接口url。如：api.baidu.com | www.baidu.com/api
2）考虑到接口数据安全性，优先选择https协议。
3）如果一个接口中有多个不同的版本，需要在url中标识体现出来。如：api.baidu.com/v1/... | api.baidu.com/v2/...
4）接口操作的数据源称之为资源，在url中一般采用资源复数形式，一个接口可以概括为对资源的多种操作方式。如：api.baidu.com/books | www.baidu.com/api/books(pk)，操作单个资源的时候，需要用到主键pk。
5）请求方式有多种，用一个url处理如何保证不混乱 ---> 通过请求方式标识操作资源的方式。
/books get 获取所有
/books post 增加一个(多个)
/books/(pk) delete 删除一个
/books/(pk) put 整体更新一个
/books/(pk) patch 局部更新一个
6) 资源往往涉及数据的各种操作方式 ---> 筛选、排序、限制。如：api.baidu.com/books/?search=西&ordering=-price&limit=3
响应数据
1) http请求的响应会有相对应的响应码，接口是用来返回操作的资源数据，可以拥有操作数据结果的状态码。status： 0(操作资源成功) ；1(操作资源失败)； 2(操作资源成功，但没匹配结果)
注：资源状态码不像http状态码，一般都是后台与前台或是客户约定的
2) 资源的状态码文字提示。如：status ok '账号有误' '密码有误' '用户锁定'
3) 资源本身。results。
注意：删除资源成功不做任何数据返回(返回空字符串)
4) 不能直接放回的资源(子资源、图片、视频等资源)，返回该资源的url链接