一一回应:
1 get, post, put, delete 方法的细化,可以很容易在上层做权限拦截,从读取,新建,修改,删除层次上就做到了,当然这个是对方法的使用比较严格。
对于一般的资源,比如 /v1/user/1/ (几个方法表示获取,创建,修改,删除),如果用你现在的方法,那要怎么表示,无论如何都会很冗余。
rest 是为了描述通用资源的管理,如果你抽象得好,绝大多数请求都是可以归类出来的。其他的你可以自行实现,比如你说的「传统」的 API 设计...
2 从 URL 和 Header 里分离参数是有特别意义的,比如
https://developer.github.com/v3/#authentication,用户认证的 Token 必须放到 Header,如果你放在 URL 里,这是一种不安全的方法。总之,敏感信息是不能带在 URL 上面的,类似 Token,sessionid,Header 是最好的选择。
3 Status Code的细分,你看看下面的描述,你觉得这些没有用的?
200: 正常,可能附带数据
201: 需要创建的对象已经存在
400: 请求参数或者格式不对
403: 没有相关的权限
404: 资源没有找到
500: 内部数据出现错误
总结:
大部分的麻烦,要考虑是不是代码写得不对,因为 rest 的这种规范,代码其实更好写的,以 java 为例子,非常好做继承和复用,统一的错误和异常处理,比如一旦 403 转到权限不足提示页面。