请求参数既在path又在body的好处
好处在哪?坏处倒是一大堆
我想不到好处,反而是这俩要不一样,很容易出bug
这个要看你怎么理解了。
比如你大厂的云服务api,它会在path中拿对应的用户唯一参数(也算用户的某个数据标识),参数就做纯参数使用。
这样的结果就是可以直接在path中提取用户的标识去数据库查找处理;参数就只做参数处理,代码上也可以少解析一层,可以拿过来就使用,就这么简单
如果你做的服务接口,代码质量很高的话,这样用的很多的。因为对服务端很方便,但是对于一些前端等等就很麻烦,组装参数都费时间
好处说不上,只是有些情况下restful希望这么做,从含义上更清晰,比如修改一个用户信息,url是/user/{userid},body中是name,age等等,这么设计是在含义上区分了这些参数,userid是用于定位的(url本来就是用来定位网络资源的,而这里面的用户就可以理解为一个网络资源,这么做很合理),其他参数才是要修改的。如果说好处也有一点点,就是新增和修改的实体类可以合并了,因为他们之间最大的差别就是有没有userid
好处在哪?坏处倒是一大堆
我想不到好处,反而是这俩要不一样,很容易出bug
这个要看你怎么理解了。
比如你大厂的云服务api,它会在path中拿对应的用户唯一参数(也算用户的某个数据标识),参数就做纯参数使用。
这样的结果就是可以直接在path中提取用户的标识去数据库查找处理;参数就只做参数处理,代码上也可以少解析一层,可以拿过来就使用,就这么简单
如果你做的服务接口,代码质量很高的话,这样用的很多的。因为对服务端很方便,但是对于一些前端等等就很麻烦,组装参数都费时间
好处说不上,只是有些情况下restful希望这么做,从含义上更清晰,比如修改一个用户信息,url是/user/{userid},body中是name,age等等,这么设计是在含义上区分了这些参数,userid是用于定位的(url本来就是用来定位网络资源的,而这里面的用户就可以理解为一个网络资源,这么做很合理),其他参数才是要修改的。如果说好处也有一点点,就是新增和修改的实体类可以合并了,因为他们之间最大的差别就是有没有userid