获取 User 下的 Product 的 URL 你会怎么写?
发布于 9 个月前 作者 tmirun 1135 次浏览 来自 问答

hi 最近有个 小问题在困扰这我 在restful 规范下想写一个获取客户(user) 的商品 (Product) url 怎么写才靠谱

方法1: /user/:id/products 方法2: /products?userId=:id

各位同伴哪个比较靠谱?或者你还有其他翻案?

7 回复

看你的业务关系,如果业务上商品实体严格从属于用户实体的,就用该方法1,然如果商品和用户是松散耦合的,各自为独立实体,就用方法2。 从个人使用REST的经验来看,方法1更多的是突出products是user实体的成员属性。

@libook 感谢你的回答,昨天和几个朋友讨论了一下,有个这方面的问题,他们的答案和你差不多,都认为方法1 是正确的,和方法2 更通用一点,

最后有个朋友指出 也可以用 /products/user/:userId

方法1: /user/:id/products (正确,但要如果以后可能要创建多个api接口 admin/:id/products, provider/:id/products) 方法2: /products?userId=:id (通用,但这个api接口内部需要很多逻辑) 方法3: /products/user/:userId (和方法2差不多,分离了这部分逻辑)

没有什么正确或不正确的,REST关注的是你的资源在业务上的关系,究竟products与user之间是什么关系:

  1. product和user之间是互相引用的关系。
  2. product是user的子实体。
  3. user是product的子实体。

1的话,根据业务需求可能最终同时存在/user/:userId?product= 和/product/:productId?user= 两组API。 2的话,就只有/user/:userId?product= 和 /user/:userId/product/:productId这样的API,要想拿到product必须先拿到所属的user实体才行。 3的话,就是/product/:productId?user= 和 /product/:productId/user/:userId这样的API,要想拿到user必须先拿到所述的product实体。

这个就像是使用OO思想来设计Class,“文档”和“公司”两个类,你可以分别写一个类,也可以从“文档”派生出“公司”,还可以从“公司”派生出“文档”,没有绝对的对错,只是看你的业务上怎么处理最方便。

设计了完美优雅的API,客户宝宝让你在URL里面加一大堆动词你还是得加……😂

@libook 学习了,赞一个

@libook 喜欢你最后者一句 这个就像是使用OO思想来设计Class

方法1是遵循restful规范的,看你选择了,你喜欢restful就用方法1,如果不喜欢无所谓哪个,能正常访问就行

回到顶部