RESTful风格接口并不适合所有情况
有时候，RESTful风格接口的确简化了资源定位以及资源CRUD的问题，但是当我们想做一些特殊操作时 ,该风格显然不适合。
RESTful风格接口组成
- 请求方法（
GET.POST,PUT,DELETE等） - 请求路径 http://
ip:port/伪资源目录/资源ID
问题
- 比如，我们在添加数据时，想对数据的某些特征值做唯一性判断，这时，想创建一个RESTful风格的接口就发现很不适合
- 首先需要验证的数据没有资源ID，就无法定位服务器资源
- 该行为显然是一种验证操作，RESTful风格没有相应的具体的请求方法
- 若请求方法为
POST,如果伪资源目录后加入操作名，那就和资源ID冲突，感觉很不RESTful
- 当我们做多资源操作时，全拼在
伪资源目录后面，要操作资源过多时，会造成url过长的问题，这种时候，把多个资源id放在body里面更为合适
解决方案
自定义接口标准
- 请求方法（
GET,POST） - 请求路径http://
ip:port/伪资源目录/操作/资源ID/资源属性
梨子
- 域名：
www.baidu.com - 伪资源目录：
user - 操作：
- 分页查询列表：
list - 添加：
add - 删除：
delete,remove - 修改：
update,edit - 查询详情：
detail - 删除多个：
remove-multiple,delete-multiple - 检查唯一性：
check-unique
- 分页查询列表：
- 资源ID:
- 用户名：
liuqi
- 用户名：
- 资源属性：
- 用户名:
username - 密码:
password - 邮件地址:
email - 电话:
phone
- 用户名:
例如
- 获取用户信息详情：GET +
http://www.baidu.com/user/detail/liuqi - 检查用户名唯一：POST +
http://www.baidu.com/user/check-unique - 只修改邮件地址：POST +
http://www.baidu.com/user/update/liuqi/email - 删除多个用户：POST +
http://www.baidu.com/user/update/liuqi/email
缺点
- 请求路径比RESTful风格的要长
- 只使用了GET,POST方法
初次学习，多有不足，若有错误或者疑问，还请多多指教
