hi 最近有个 小问题在困扰这我 在restful 规范下想写一个获取客户(user) 的商品 (Product) url 怎么写才靠谱
方法1: /user/:id/products 方法2: /products?userId=:id
各位同伴哪个比较靠谱？或者你还有其他翻案？
看你的业务关系，如果业务上商品实体严格从属于用户实体的，就用该方法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之间是什么关系：
- product和user之间是互相引用的关系。
- product是user的子实体。
- 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，“文档”和“公司”两个类，你可以分别写一个类，也可以从“文档”派生出“公司”，还可以从“公司”派生出“文档”，没有绝对的对错，只是看你的业务上怎么处理最方便。
