假设来自剩余服务A的资源X（http://example.com/a/foo/7）需要持有对来自剩余服务B的第二资源Y（http://example.com/b/bar/1）的引用。
一个人如何坚持引用？
当前，我将Y的整个URI（作为字符串）存储在服务A的持久层中。这是一种常见/有效的方法吗？ 从Y的URI中提取id（1）似乎对我来说是错误的，因为我将在服务A中实现有关服务B的URI结构的假设。
您如何解决此问题？
谢谢！
答案 0 :(得分：1)
让我们与一些实际的业务领域进行讨论，然后答案就会变得有意义。
第一个例子：
X代表Amazon Order Service中的订单实体，Y代表Customer Service中的客户。
现在，当从Order Service从Amazon获取订单时，您还想显示一些基本的客户详细信息，并链接到customer Object以转到Customer Detail页面。
在这种情况下，我要做的是在创建订单时复制订单实体中客户的一些基本属性（customerName，customerArea）。
还存储customerId，customerType。由于用于获取客户的API是公开的，并且还提供给各种内部服务，因此Order Service将进行服务发现并创建URL和调用。在这种情况下，客户服务通常不会停止支持旧方法（即使他们正在构建新方法）。
因此，仅存储ID是一种解决方案。
情况2：
Amazon订单实体想存储交货详细信息，而交货合作伙伴是某些第三方实体，例如DHL，那么如果DHL提供URL来获取订单的交货更新，那么在这种情况下，我将只存储URL。
通常，我更喜欢存储ID和服务类型以及一些基本详细信息，以创造良好的客户体验，并且还避免使用一种额外的服务api来获取基本详细信息，例如客户名称。
存储直接URL时需要使用第三方URL。
此外，如果您能给出这样的业务案例示例，我们可以进行更好的讨论
答案 1 :(得分：0)
IMO参考应按原样存储。从引用中获取实际数据的方式不应成为数据的一部分，而应随时间而变化。 我将它们存储为外部参考的参考（只是为了画出我们服务之外的参考图片），并将其与逻辑结合以查询数据。
URL非常易变，可能会更改。根据经验，永远不要在数据库中保留url，并且应该依靠服务发现来确定服务的位置，即使该服务位于您自己的基础设施之内。</ p>
这不是一个假设，它是一个合同，它可能会更改，如果更改，则您的服务将是依赖服务，必须进行适当的更改
按照您的逻辑，即使您保留url，对它的响应仍然是你们俩都遵守的契约。