我们正在从单片架构转向微服务架构应用程序，我们仍处于规划阶段，我们想知道构建它的最佳实践是什么。
假设我们有两项服务：
每个用户都有多个设备
什么是要求服务器获取所有用户设备的最常见，更清晰和正确的方法？
1- {api-url} / User / {UserId} / devices
需要另一个HTTP请求与Device服务通信。
对于用户X，从用户服务获取链接的设备。
// 要么
2- {api-url} / Device / {UserId} / devices
对于用户X，从设备服务获取链接的设备。
有许多经典模式可用于解决微服务中的此类问题。你有2个微服务 - 1个用户（微服务A）和1个用于设备（微服务B）。微服务的基本原则是为每个微服务建立一个单独的数据库。如果任何微服务想要彼此交谈（或从另一个微服务获取数据），他们可以但他们会使用API来实现。 2个微服务之间通信的另一种方式是事件。当微服务A中发生某些事情时，它会引发事件并将其推送到中央事件存储或消息队列，而微服务B将订阅由A发出的部分或全部事件。
我想在你的域中，A会有类似的方法 - 添加/更新/删除用户，B会添加/更新/删除设备。每个用户都可以拥有自己唯一的ID和其他数据字段，如姓名，地址，电子邮件等。每个设备都可以拥有自己唯一的ID，用户ID和其他数据字段，如名称，类型，制造商，价格等。无论何时“添加“设备，您可以向设备微服务发送POST请求或命令（如果您使用CQRS），其中包含有关设备+用户ID的数据的请求，它可能会引发一个名为”DeviceAdded“的事件。它还可以包含与“更新和删除”相对应的事件，如“DeviceUpdated”和“DeviceRemoved”。微服务A可以订阅事件--B发出的“DeviceAdded”，“DeviceRemoved”和“DeviceUpdated”事件，每当引发任何此类事件时，它将处理该事件并将该事件反规范化为其自己的设备数据库（其中你可以打电话给UserRelationships）。将来，它也可以监听来自其他微服务的事件（因此这里的模式可以扩展和扩展）。
所以现在要获得用户拥有的所有设备，您所要做的就是在用户微服务中设置一个终点，例如“http：// {microservice-A-host}：{port} / user / {user-id} / devices“它将通过在自己的UserRelationship数据库中查询用户ID来返回设备列表，这些数据库必须通过事件进行维护。
好参考在这里：https://www.nginx.com/blog/event-driven-data-management-microservices/
它可能真的是两种方式，但根据我的喜好，我会选择将它放在/ Devices / {userId} / devices下，因为您正在寻找具有用户ID的设备。我希望这有帮助。祝你好一个！
您正在从服务请求资源，资源是设备，服务是设备服务。从休息的角度来看，您正在寻找资源，您的服务正在提供各种方法来操纵该资源。
可以使用以下URL。
[GET] ../device?user_id=xyz
设备信息可以通过../device/{device_id获取
话虽如此，如果你有一个提供用户和设备数据的服务，那么下面的内容是有意义的。
[GET] ../user/{userId}/device
请注意，这只是一个命名约定，你可以选择最适合你的东西，选择一个并抓住它。暴露api时，一致性更为重要。
微服务架构的一个核心原则是定义每个微服务的明确边界和责任。
我可以说它与SOLID的单一责任原则相同，但在宏观层面上。我们得到以下原则：
你的问题是
..proper方式要求服务器获取所有用户设备
它是设备服务和用户服务的100％责任，对设备一无所知。
我可以看到你只考虑路由术语（是的API一致性也很重要）。
从一侧来看，更好更逻辑的URL是/api/users/{userId}/devices - 您尝试获取用户的设备，这些设备属于用户。
从另一方面，您可以使用/api/devices/user/{userId}（/api/devices/{deviceId}）等路由，路由系统可以更轻松地处理这些路由，以向Devices服务发送请求。
考虑到其他限制，您可以选择适合您设计的选项。
还有一点：
需要另一个HTTP请求与Device服务通信。
在您的解决方案的体系结构中，您可以创建一个额外的特殊且独立的组件，将请求路由到所需的微服务，不仅可以从一个微服务直接调用到另一个微服务。
您应该只查询设备服务。
并将用户ID视为设备服务中的过滤器。例如：您应该搜索userid，类似于您根据设备类型搜索设备的方式。只是另一个过滤器
例如：/ devices？userid =
您还可以在设备服务中缓存用户的一些基本信息，以节省获取用户数据的往返次数
使用微服务，这两个选项都没有错。然而device api更有意义，而且我更喜欢
GET ../device/{userId}/devices
过度
GET ../device?user_id=123
有两个原因：