RESTFul API 特点解析

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 频繁的抓取数据，这时候也可以记录日志进行观察。