假设来自 rest-service A 的资源 X(http://example.com/a/foo/7) 需要持有对来自 rest-service B 的第二个资源 Y(http://example.com/b/bar/1) 的引用。
如何保持引用？
目前我将 Y 的整个 URI（作为字符串）存储在服务 A 的持久层中。这是一种常见/有效的方法吗？ 从 Y 的 URI 中提取 id(1) 对我来说似乎是错误的，因为我会在服务 A 中实现关于服务 B 的 URI 结构的假设。这是正确的吗？
你如何解决这个问题？
谢谢！
【问题讨论】：
标签： rest microservices
让我们与一些实际的业务领域讨论它，然后答案就会有意义。
第一个例子：
X 代表亚马逊订单服务中的订单实体，Y 代表客户服务中的客户。
现在，在通过 Order Service 从 Amazon 获取订单时，您还希望显示一些基本的客户详细信息并链接到客户对象以转到客户详细信息页面。
在这种情况下，我要做的是在创建订单时复制订单实体中客户的一些基本属性（customerName、customerArea）。
还存储 customerId、customerType。由于获取客户的 API 是公开的，并且还暴露给各种内部服务，Order Service 将进行服务发现并创建 URL 和调用。在这些情况下，客户服务通常不会停止支持旧方式（即使他们正在构建新方式）。
所以只存储 id 是一种解决方案。
案例 2：
亚马逊订单实体想要存储送货细节，而送货合作伙伴是像 DHL 这样的第三方实体，那么如果 DHL 提供了一个 URL 来获取订单的送货更新，在这种情况下，我将只存储该 URL。
一般来说，我更喜欢存储 id 和服务类型以及一些基本细节，以创造良好的客户体验，同时避免使用额外的服务 api 来获取客户姓名等基本细节。
当它是第三方 URL 时，存储直接 URL 是有意义的。
另外，如果你能举出这样的商业案例的例子，我们可以更好地讨论
【讨论】：
GET http://example.com/books/123456 { “title“: “lorem ipsum“ } 。您将如何在 CategoryService 中存储对图书的引用？
IMO 参考应按原样存储。您如何从参考中获取实际数据不应该是数据的一部分，而是可能会不时改变的逻辑。 我会将它们存储为外部参考的参考（只是为了描绘参考在我们的服务之外）并将其与查询数据的逻辑相结合。
网址非常不稳定，可能会发生变化。根据经验，你永远不应该在你的数据库中保留 url，并且应该依靠服务发现来识别服务在哪里，即使它在你自己的基础设施中。
这不是假设，而是合同，可能会发生变化，如果发生变化，您的服务将是依赖服务并且必须做出适当的更改
同样按照你的逻辑，即使你保留了 url，对它的响应仍然是你们双方都遵守的合同。
【讨论】：