第三方API调用的Web应用程序体系结构

我正在构建一个简单的搜索引擎，它将用户提交的搜索查询作为输入并输出适当搜索结果的列表。搜索查询最终会被发送到第三方API，这会大大提高搜索结果的生成。第三方API调用的Web应用程序体系结构

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

在这两种方法之间进行选择时需要注意什么？

回答这个问题是不太可能的。它太广泛了。它提出了一般性意见，没有具体说明具体任务的细节。那么你如何期望得到一个真正有意义的答案呢？ – arkascha

[** Here **]（http://programmers.stackexchange.com/a/138565）是您可以考虑的答案。这取决于您愿意向外界展示多少API逻辑，以及您认为它将以最快/最有效的方式运行的位置。 – blex

就个人而言，我会使用选项＃1。这使您在更改第三方API的情况下获得最大的灵活性。而且，我总是倾向于实现任何业务逻辑/转换服务器端 - 谁知道，您甚至可能最终需要执行相同搜索的其他UI。 –

使用选项＃1给你喜欢的几个优点：

您有一个观点一个API。它为您的架构带来了一些清晰。
你可能有很多页面/窗口/任何使用相同的搜索API。如果第三方API更改或移动到另一个域，或者做了一些让您更改代码的内容，则可以在服务器上只修复一个API方法，而不是修复所有客户端。
如果第三方搜索引擎本身无法进行翻译，您可以使用搜索查询执行一些其他更改，例如翻译它。形式上，你可以实现一些额外的逻辑。

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

2014-12-28 23:01:40 Alagunto

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

回答