代码审查的时候， 突然发现有个同事写的接口， 觉得有些事情还是要严格要求， 不然他们写出什么样的代码真的不敢想象。
为什么需要Restful？
URL具有很强的可读性，且具有自描述性
规范化请求过程和返回结果
可提供OpenAPI，便于第三方系统集成，提高互操作性
提供无状态的服务接口，降低复杂度，可提高应用的水平扩展性
示例：
/版本号/资源路径
/v1/tags/{tag_id}
/v1/users?[&keyword=xxx][&enable=1][&offset=0][&limit=20]
Rest 其实并非需要严格遵循的规范， 可以理解为一种风格， 统一风格，
1. 版本号
openAPI 设计是必须引入版本号， 因为旧版本的接口已经有人在使用， 在使用方无法升级接口的前提下， 旧版本的接口必须保留并持续提供服务。
命名版本号可以解决版本不兼容问题，在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下，我们会在 url 中保留旧版本号，并同时兼容多个版本
【GET】 /v1/users/{user_id} // 版本 v1 的查询用户列表的 API 接口
【GET】 /v2/users/{user_id} // 版本 v2 的查询用户列表的 API 接口
2、资源路径
URI 不能包含动词，只能是名词（命名名词的时候，要使用小写、数字及下划线来区分多个单词）。
资源的路径应该从根到子依次如下:
/{resources}/{resource_id}/{sub_resources}/{sub_resource_id}/{sub_resource_property}
【POST】 /v1/users/{user_id}/roles/{role_id} // 添加用户的角色
有的时候，当一个资源变化难以使用标准的 RESTful API 来命名，可以考虑使用一些特殊的 actions 命名。
/{resources}/{resource_id}/actions/{action}
【PUT】 /v1/users/{user_id}/password/actions/modify // 密码修改
3、请求方式
【GET】 /users # 查询用户信息列表
【GET】 /users/1001 # 查看某个用户信息
【POST】 /users # 新建用户信息
【PUT】 /users/1001 # 更新用户信息(全部字段)
【DELETE】 /users/1001 # 删除用户信息
￥4、查询参数
RESTful API 接口应该提供参数，过滤返回结果。
【GET】 /{version}/{resources}?offset=0&limit=20
复杂的查询， 也可以使用post方法， 将查询参数放到body中， 但后端需要封装统一的查询参数结构体，
5、多租户资源操作
如果对资源的操作涉及到租户， 租户ID默认通过header 传递，
6、接口返回
统一使用封装好的Result 返回接口数据,
选择适合的Http 状态码，
对于OpenAPI, 接口如发生错误， 应返回对应的错误码
