RESTFul API 基于 REST 的 API 设计理论：
- 轻
- 通常来说，使用 JSON 描述数据
- 无状态（第二个请求不需要依赖第一个请求）
REST 提倡基于资源，增删改查都是对于资源状态的改变。
表示资源的方式是通过 url，所以 url 都提倡为名词。
通过 http 动词来描述资源的增删改查，例如：GET、POST、PUT、DELETE。
设计：
错误示例：
/getmovie/:mid
正确示例：
GET: /movie/:mid
RESTFul API 实践：
- http 动词：
POST：创建
PUT：更新
GET：查询
DELETE：删除 - 明确意义的状态码：
常用：
404 - 资源没有找到
400 - 参数校验错误
200 - 查询操作 GET 请求执行成功
201 - 创建操作 POST 请求执行成功
202 - 更新操作 PUT 请求执行成功
401 - 未授权、没有权限访问该接口
403 - 有权限，但由于特殊原因，不允许访问（防止A用户传B用户id来操作B用户的数据）
500 - 服务器的未知错误，1.未知的 bug。2.我知道是哪里的 bug，但这是我的服务器的原因，并不想让客户端知道。 - 错误码：
自定义的错误ID号 - 统一描述错误：
错误码、错误信息、当前URL - 使用 Token 令牌来授权和验证身份。
- 版本控制
- 测试与生产环境分开
api.xxx.com
dev.api.xxx.com - 最好有一份比较标准的文档
RESTFull API 异常分类：
- 由于客户端行为导致的异常（没有通过验证器，没有查到结果）
通常不需要记录日志，需要向客户端返回具体的信息 - 服务器自身异常（代码错误，调用外部接口错误）
通常记录日志，不向客户端返回具体原因
以上只是通常情况，具体情况具体分析。比如说有个客户端 ip 频繁的抓取数据，这时候也可以记录日志进行观察。
网友评论