调用另一个 REST API 的 REST API答案

【问题标题】：REST API that calls another REST API调用另一个 REST API 的 REST API
【发布时间】：2017-12-21 01:41:56
【问题描述】：

让一个 REST API 调用另一个 REST API 是否正确的编程实践/软件设计？如果不是，推荐的处理这种情况的方法是什么？

【问题讨论】：

【解决方案1】：

如果我正确理解了您的问题，那么是的，这是非常常见的。

我猜你是在描述以下内容：

客户端向正在服务的 Server-1 进行 API 调用此请求向 API Server-2 发出另一个请求，获取来自 Server-2 的响应，进行一些重新格式化或数据提取，以及打包起来响应客户端？

这种事情一直在发生。不利的一面是，除非 Server-1 和 Server-2 之间的连接延迟非常低（例如它们在同一个网络上），并且使用的带宽很小，否则客户端将不得不等待相当长的时间响应。显然，两个后端服务器之间可以有缓存来帮助缓解这种情况。

这与 Server-1 对数据库进行 SQL 查询以响应请求几乎相同。

您的问题的另一种解释可能是客户端要求服务器 1 将服务器 2 将获取并异步执行的操作排队。这也很常见（例如 Google 抓取您的网站的方式）。这种情况下，Server-1 会立即响应 Client，而无需等待 Server-2 执行的操作结果。在这种情况下，消息队列或数据库表通常用作服务器之间的中介。

【讨论】：

如果你正在设计一些 API 怎么样。假设您有方法 X 和 Y。Y 调用 X 然后执行其他操作？这是一个好习惯吗？在我看来，它不是。客户应该调用 X，然后调用 Y。Y 不应该重复 X 所做的事情。但我找不到任何关于它的书面规则。另外，有没有什么情况可以让 Y 调用 X？
其实，发现这个支持我的论点en.wikipedia.org/wiki/Single_responsibility_principle
@chepukha 取决于 X 和 Y 是否被认为处于同一“级别”。 API 调用较低级别的 API 来完成工作是无处不在的，这是该 API 必要功能的一部分。 Y是否依赖于X？还是辅助的？以area() API 为例——它需要调用multiply() API 来执行其功能。这并不违反 SRP。

【解决方案2】：

另一种方法是让您的 REST API(1) 将请求详细信息存储到队列表中。制作一个后端，每隔 100 毫秒检查一次队列表。该后端将调用另一个 REST API(2)。

在您的 REST API(1) 中，只需创建一个循环来检查队列上的事务是否已被处理。如果是，则获取流程详细信息并将其返回给客户端，如果否，则继续循环直到流程完成

【讨论】：

一遍又一遍地轮询数据库效率非常低，被认为是反模式