用于第三方 API 调用的 Web 应用架构答案

【问题标题】：Web app architecture for third party API calls用于第三方 API 调用的 Web 应用架构
【发布时间】：2014-12-28 22:14:06
【问题描述】：

我正在构建一个简单的搜索引擎，它将用户提交的搜索查询作为输入并输出适当的搜索结果列表。搜索查询最终会发送到第三方 API，该 API 负责生成搜索结果的繁重工作。

有两种方法可以处理这个工作流程：

在这两种方法之间进行选择时有哪些注意事项？

【问题讨论】：

这个问题真的无法回答。它太宽泛了。它询问一般意见，而不指定有关特定任务的任何细节。那么你如何期望得到一个真正有意义的答案呢？
Here 是您可以考虑的答案。这取决于您愿意向外界公开多少 API 逻辑，以及您认为它将在哪里以最快/最有效的方式运行。
就个人而言，我会使用选项#1。这为您在更改第三方 API 的情况下提供了最大的灵活性。而且，我总是更喜欢在服务器端实现任何业务逻辑/转换——谁知道呢，你甚至可能最终得到需要执行相同搜索的其他 UI。

【解决方案1】：

使用选项 #1 可以为您带来一些优势，例如：

您有一个用于一个视图的 API。它使您的架构更加清晰。
您可能有很多页面/窗口/任何使用相同的搜索 API。如果第三方 API 更改或移动到另一个域或执行某些操作导致您更改代码，您可以只修复服务器上的一种 API 方法，而不是修复所有客户端。
如果第三方搜索引擎无法自行完成，您可以对搜索查询进行一些额外的更改，例如翻译它。形式上，您可以实现一些额外的逻辑。

使用选项 #2 可以减轻服务器的负担。

【讨论】：

顺便说一句，如果你真的很犹豫，你可以执行一个技巧：从你的客户端调用你服务器的API，但从服务器的API只是将客户端的请求重定向到第三方API。这将减轻您服务器的负担，并使您能够在不更改客户端代码的情况下更改您的选择。