我正在开发一个使用微服务架构的项目。
有两项服务:
- UserAPI:所有与用户相关的东西都在这里。
- OMS:所有与订单相关的事情都来这里。
我需要根据以下过滤器提供订单:
- 按用户 ID
- 按日期
- 按状态
- 按用户电话号码
- 以上内容的混合
所以我创建了一个 API
path/orders?date=12/11/2016&status=delivered&phone=1111111111
现在我需要通过用户 ID 提供用户订单。那么什么是好的休息设计:
- 在现有 API 的查询参数中添加用户 ID,例如
path/orders?user_id=1
- 创建单独的 API 路径
user/{user_id}/orders
最佳答案
您的两个选择都可以。但有不同的语义。
path/orders?user_id=1
这是按订单查找。例如,可以查找订单以进行一些统计分析。订单可以通过不同的参数进行过滤,用户 ID 就是其中之一。对于这一点(当订单是主要关注点时),上面的 URI 策略就很好。
现在,另一方面,您可能想要查找用户并查看他们的订单。也许对他们的点餐习惯做一些分析。在这里您需要用户信息及其订单。这是您的第二个 URI 方案会更好的地方
user/{user_id}/orders
这些是属于用户的订单。所以这是一种关系。这就是这个 URI 方案效果更好的地方。
所以说,同时拥有这两种选择并没有什么问题。您只需遵循何时应使用每个选项的语义即可。
关于java - 订单管理系统的Rest API设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40799797/