RESTful API通俗理解

关于定义

REST翻译过来就是Representational State Transfer的缩写，即表现层状态转换，是Fielding提出的一个设计原则… ，我第一次看这也是有些晕头转向，如果你是第一次，能理解就理解，不能理解现在也没有很大的关系，以后慢慢来；（http://www.ruanyifeng.com/blog/2011/09/restful.html推荐参考阮一峰老师的文章理解REST）
通俗的理解REST主要是来定义接口名字的，关于如何定义是有一些规则可询的：

关于设计规则

动词+宾语

• 通过HTTP动词类型来描述操作，通过url宾语来确定资源
  当我们通过客户端来操作数据时，一般都是通过动词+宾语的形式来表达的，如GET/phones这种形式：GET是HTTP的GET类型用来获取资源的，phones代表着要获取哪一类资源；
• 如下案例对手机数据进行操作

GET/phones  获取所有的手机
POST/phones  创建手机集合
PUT/phones/x  更新指定的某个手机
DELTET/phones  删除手机这个集合

• 注意的几点
  • 关于宾语必须是名词，同时最好是复数形式：phones、books、friends
  • 避免多级混轮，一般很多数据需要多级分类，对于多级分类，尽量表名第一级，后面的用字符串查询的方式表示：
  • GET/phones/2/HUAWEI/12 --------->不如：GET/phones/2?HUAWEI=12的形式

返回的状态码

状态码分五个级别：

1xx
2xx 代表成功
3xx 代表重定向
4xx 客户端错误
5xx 服务段错误

常用的状态码

2xx
200 访问成功
201 创建成功
203 修改成功
204 删除成功
3xx
301 302 永久暂时重定向 一般用不到这个API，这个会由应用级别返回，直接跳转
303 参考另一个url，暂时重定向，与301.307区别在于303用于POST、PUT、DELETE请求的
4xx
400 服务器不理解你的而操作
401 身份验证失败
403 权限验证失败
404 访问的页面不存在
410 请求的地址已经转移，此地址不可用
5xx
500 服务器崩溃

服务器回应

• 回应尽量是json格式或者是xml格式，避免是穿文本
  API 返回的数据格式，不应该是纯文本，而应该是一个 JSON 对象，因为这样才能返回标准的结构化数据。所以，服务器回应的 HTTP 头的Content-Type属性要设为application/json

参考：
http://www.ruanyifeng.com/blog/2018/10/restful-api-best-practices.html