当相关资源属于不同的微服务时,如何处理REST API路径？

Question

我有两个微服务:

• UserService,定义路径,例如/ users,/ users /:id;
• MessageService,定义诸如/ messages,/ messages /:id之类的路径.

此外,MessageService中的每条消息都有一个属性user_id,它引用UserService中的用户.

现在,假设我想列出给定用户的所有消息.现在我可以想到以下方法:

1. 如果我想遵循最好的REST API实践,像/ users /:id/messages这样的路径似乎是最好的方法.但是,在我看来,我无法在MessageService中定义这样的路径,因为我将它紧密耦合到UserService.我认为以/ users开头的路径应该只属于UserService.
2. / messages？user_id =:id所以我可以使用现有的/ messages路径并按属性(user_id)添加过滤器.不确定是否是一个好习惯.
3. 将API网关放在微服务之前,并从/ users /:id/messages创建一个代理到/ messages？user_id =:id.这允许客户端使用最友好的REST路径,同时保持微服务松散耦合.

哪种方法最合适？

Answer 1

如果您已经设计了微服务，其中用户和消息是两个不同的域/微服务，那么您最好的选择将是设计一个结合这两种服务并提供客户需求的边缘服务。例如，该服务可以是

/messages_by_user/:id

请记住，微服务主要提供CRUD对域资源的操作，但客户端需要的不仅仅是对资源的 CRUD 操作，在这种情况下，您应该始终考虑创建边缘服务来满足客户端的需求。

如果您还没有实现这些服务，那么我建议将用户和消息放入同一个微服务中，并将用户视为消息的子资源。在这种情况下，所有以下路径都是有效的。

/messages
/messages/:id
/message/:id/users
/messages/user/:id

当您设计微服务时，您需要在更有意义的方面取得平衡。虽然理论上每个资源及其CRUD操作都应该有一个单独的微服务，但实际上，只要不影响服务的可扩展性和性能，您可以组合一些相关资源并使它们成为子资源。

Answer 2

这个问题没有正确或错误的答案。IMO，这取决于消息是独立资源还是域逻辑中用户资源的一部分。

如果消息始终属于单个用户，那么您可以将用户的消息视为消息集合中的子资源或分层划分，我可能更喜欢第一个 URI 方案。在这种情况下，我可能会选择类似的路径/user/:id/messages而不是复数“用户”。或者将用户 ID 放在消息后面，例如：/messages/user/:id

如果消息本身是您域中的一个实体，或者可以属于多个用户（例如电子邮件消息），那么使用查询字符串方案过滤消息会更有意义。