订单管理系统的Rest设计

Question

我正在做一个使用微服务架构的项目。

有两项服务：

1. UserAPI :所有与用户有关的东西请到这里来。
2. 所有与订单有关的东西都到这里来。

我需要提供基于以下过滤器的订单：

1. 按用户Id
2. 按日期
3. 按地位分列
4. 按用户电话号码
5. 以上混合

所以我创建了一个API

path/orders?date=12/11/2016&status=delivered&phone=1111111111

现在我需要通过用户ID为用户提供订单。所以，这是一个很好的rest设计：

1. 在现有API (如path/orders?user_id=1 )中的查询param中添加用户ID
2. 创建单独的API路径user/{user_id}/orders

Answer 1

你们两种选择都没问题。但是有不同的语义。

path/orders?user_id=1

这是按命令查的。例如，订单可能是用来做一些统计分析的。订单可以通过不同的参数进行过滤，用户id就是其中之一。对于这一点(当订单是主要兴趣时)，上面的URI策略很好。

另一方面，您可能希望查找用户并查看他们的订单。也许可以对他们的点菜习惯做些分析。在这里，您需要用户信息以及他们的订单。这是您的第二个URI方案更好的地方。

user/{user_id}/orders

这些是属于用户的订单。所以这是一种关系。这是这个URI方案工作得更好的地方。

所以真的有两种选择都没有错。您只需要遵循何时使用每一种语言的语义。