REST应该在哪里结束？

Question

假设有用户和订单

特定用户的订单列表

你可以做

• /user/3/order_list
• /order/?user=3

哪一个是首选，为什么？

Answer 1

可选参数往往更容易放入查询字符串中。

如果你想返回一个404错误，当参数值不对应一个现有的资源，那么我会倾向于一个路径段参数。例如/ customer/232其中232不是有效的客户ID。

如果你想返回一个空列表，那么当没有找到该参数时，查询字符串参数。例如/ contacts？name = dave

如果一个参数影响整个URI结构，那么使用一个路径语言参数/en/document/foo.txt与/document/foo.txt?language=en

如果唯一标识符位于路径而不是查询参数中。

路径是友好的搜索引擎/浏览器历史/导航。

Answer 2

当我开始创建一个API时，我正在考虑同样的问题。
Video from apigee。帮助我很多。

简而言之，当您决定构建一个API时，您应该决定哪个实体是独立的，哪个实体只与某人有关。
例如，如果您有创建/更新/删除操作的订单的特定端点，则可以使用第二种方法/order/?user=3。
另一种方式，如果订单只有一个表示，取决于用户，他们没有任何特殊的交互，那么你可以先行。

There is also nice article about best practice

Answer 3

REST的整点是资源。你应该尝试尽可能地将它们映射到你将要得到的实际要求。我绝对不会把它称为order_list，因为这看起来像一个动作（你正在“列出”订单，而GET应该足以告诉你，你正在得到的东西）

所以，首先我想你应该有/users代替/user，然后把它作为一个树状结构：

• 卖家（缺乏一个更好的名字）可以有多个用户
• 用户可以有多个订单
• 订单可以有多个项目

所以，我会去这样的事情：

• 卖家可以看到它的用户提供yourdomain.com/my/users
• 可以yourdomain.com/my/users/3
• 的这些订单可以看到的单个用户的详细信息单个用户可见yourdomain.com/my/users/3/orders
• 单个订单的项目可以看到与yourdomain.com/my/users/3/orders/5