使用 restful 接口规范开发时我碰到的几个槽点…

restful提供了一种接口规范,本意是让路由变得更加易懂,不过既然是规则那么就有束缚,想在项目中采用这个的同学们可以参考一下

路由嵌套太要命

$~~~~~~$如果存在这种city/3/zoo/2/animal/1这样的查询路由你怎么说? 多层嵌套在我看来反而不如?city=3&zoo=2&animal=1这种 query 来的方便直接,尤其是在后台的开发中这种目录结构会让人痛不欲生,而且很多情况下我们进行列表展示的时候数据不是从一个表里取出来的,有时甚至需要跨业务或者调第三方的进行组合,这种情况下路由是不是要很长? restful路由里需要显示出要操控的资源,这资源种类一多url 就会变得长长长,反而不如像select/animal-list这样来的简单直接

权限问题

$~~~~~~$这是由于上个问题引申出来的, 像city/{cid}/zoo/{zid}/animal/{aid}这种路由规则的权限怎么去维护? 而且 rbac 在国内的应用来说很是常见,我们目前的解决方案也是

1
2
3
4
5


$route = [
    'select/animal' => 'city/{cid}/zoo/{zid}/animal/{aid}',
    //.....
];

这样给这类的路由出一个给机器看的路由,长期下来如果当前开发人员走了后续接手的程序员会很绝望

路由规则让人头秃

$~~~~~~$restful的路由命名核心就是将动词转换成名词,这个就看你的词汇量能不能跟上业务了,最典型的就是用户登录注册,user/login和user/register这种明显不符合啊,如果用session/{id}这种路由又显得怪怪的

如果出现文件类型接口的怎么办?

$~~~~~~$举个例子就是如果我有导出 excel 或者生成二维码的需求,那么这个路由算是文档操作里面的还是业务资源底下的?这一类的操作大部分都是查的居多,增删改几乎没有,这种接口都是单独写路由规则的. 还有一点,我们这边采取的前后端分离通常都是 application/json 格式传输数据,当碰到文件上传的时候还是老老实实的用multipart/form-data,请求方式要单独写,php56的还会提示$HTTP_RAW_POST_DATA即将被php://input替换

回归到参数提取的问题

$~~~~~~$还是查找这一块,路由很受限,举个例子:我需要查当前某个动物园的动物种类,按名字首字母降序排序,那么我应该是GET /zoo/3/animal?sort=-1&slabel=name, 需要组成这个路由首先要前端兄弟把指定的 id 给拼出来,然后其他的参数拼到后面,或者其他的参数放到header里面,那么后台兄弟就要先把路由中的参数给剔出来,然后再去某个地方把剩余的参数给拿到…累不累? 查询条件多的情况下是不是还和原来一样,而且还多了提取url中参数的操作?

理论上在查询的时候是可以指定显示字段的

$~~~~~~$GET /zoo?field=name,id,desc 查询的路由把暴露字段的权利开放给了调用方,那么如果有人操作不规范或者直接就是是坏,每次请求我都取全量字段内容,那么我的带宽不要钱啊?mysql 的 I/O 也是压力啊

总结

$~~~~~~$restful接口在猛一看很美好,但是需要结合自己实际业务是不是适配这套规则,不要强行为了restful而restful, 一些小而美的工具可以用这种规范,中大型的业务真的要慎重考虑