Web services 使用第三个restful服务协调两个restful服务交互的最佳方式是什么？

我有3个restful服务（ServiceA、ServiceB和ServiceC），它们处理2个资源（ResourceA和ResourceB）。资源的媒体类型是application/hal+json

• 服务A生成资源A
• 服务B消耗资源A并产生资源B
• ServiceC通过从ServiceA获取ResourceA并将其发布到ServiceB来协调ResourceB的生产

我认为基本上有两种方式来组织这种互动

服务C作为资源直接中介

• ServiceC从ServiceA获取完整的资源A
• 服务C将其发布到服务B
• ServiceB返回ResourceB

服务C作为间接中介的资源

• ServiceC仅获取指向ServiceA上ResourceA的链接（例如，通过ResourceA创建上的Content Location标头）
• ServiceC将此链接发布到ServiceB（使用HAL媒体类型的链接rel）
• ServiceB直接从ServiceA获取完整的资源A
• ServiceB返回ResourceB

第一种方法似乎是“经典”方法，而第二种方法更便宜，因为只有一个完整的ResourceA传输（ServiceA->ServiceB），而不是两个（ServiceA->ServiceC->ServiceB）。理想情况下，对于足够大的资源，第二种方法会更好

---

使用第二种方法有什么问题吗？这被认为是“反模式”还是在某种程度上不安全/不可推荐？有更好的交互模式吗？

您可以使用任何方法。在第二种方法中，您需要确保ServiceA可以从ServiceB访问。如果可以访问，那么实际上我无法猜测为什么我们需要完全独立的服务，即服务C来协调。ServiceB可以直接订阅ServiceA中的事件。如果您计划使用某种轮询，那么建议您看看哪些轮询可以减少网络呼叫并提高服务器性能。

ResourceA可以是zip文件、视频或大型日志文件。我不确定订阅服务是否真的那么RESTful。它给服务带来了一些负担。如果服务非常流行，并且某些资源正在更新，则服务器需要通知每个订阅者更改，这可能会降低总体吞吐量，尤其是在资源频繁更改的情况下。HTTP提供了灵活的缓存机制和条件GET请求，如果正确使用，可以大大减少请求数量或处理时间。当然，这在所有情况下都是不可能的，但如果资源经常更新，那么就需要经常轮询服务器。在这种情况下，可以使用批处理，如下所述：假设客户机真的希望了解任何更改。有时，客户端只对最后一个状态感兴趣，而对之前的n个状态不感兴趣。通过类似服务器推送的系统，每次更新都会通知客户端，而推送可能会跳过这n次更新。类似于“服务器推送”的架构也可以使用客户端运行侦听服务的回调URL来实现——不过，这不是RESTful IMO，因为客户端需要明确了解服务和所需回调。大量HTTP客户端将无法满足此要求。如果客户端只对上次状态更新感兴趣，则在订阅时，可以将此通知给客户端感兴趣的更新所在的服务器，以便服务器只发送所需的更新。我同意，“服务器推送”将需要回调，而基于浏览器的http客户端将无法满足这一要求，这里的问题是服务之间的问题，在这方面是答案。