谁与 API (REST) 对话？Web 客户端与服务器？

Question

在我的应用程序架构中，我有以下组件：

• 手机客户端
• 应用程序接口 (REST)
• 网络客户端
• Web 服务器（用于 Web 客户端）

手机正在与 api 对话，这是显而易见的。但是，我想知道哪个 Web 组件应该与 api 通信。

一开始，我开始将其制作成服务器端。然后我意识到服务器只是调用 api，客户端也可以这样做 - 那么为什么不将这些调用委托给客户端呢？那是：

1. 请求：客户端 -> 服务器 -> api
2. 响应：api -> 服务器 -> 客户端

我们得到：

1. 请求：客户端-> serevr + 客户端-> api
2. 响应：服务器 -> 客户端，api -> 客户端。

它的优点是我们的服务器必须进行更少的网络调用，从而减少带宽。现在客户端可能需要增加一点带宽，但不需要处理所有用户。此外，客户端的整体加载时间没有增加（我认为？），因为客户端无论如何都必须等待 api 响应；无论它是否来自服务器。

因此，目前，我的网络客户端正在直接与网络对话。但是，感觉有点奇怪，特别是在身份验证方面。

1. 这是正确的选择吗？
2. 两者之间有更好的选择吗？
3. 这个选择有更多的优点还是缺点

Answer 1

将客户端配置为通过中间 Web 服务器进行操作并不是一个糟糕的设置，而且可能更可取。

如果您的 Web 服务器仅提供静态内容并将 API 请求传送到后端，那么它可能可以支持许多 API 实例的流量。这意味着您可以通过拥有多个 API 实例来增加容量，并在它们之间实现 Web 服务器负载平衡。

此外，您可以通过仅在内部网络上访问 API 并通过可公开访问的 Web 服务器路由调用来减少托管环境的攻击面。这样你还可以选择发布多少API接口。

最后，您可以在一处处理身份验证。如果身份验证由 Web 服务器处理，并且它在将每个调用路由到 API 服务器之前检查每个调用的身份验证，那么您的 API 服务器就少了一件需要担心的事情（这假设您的 API 服务器只能在您的内部网络上访问，如上所述） 。）您甚至可以在此时实现身份验证方案，以便用户只能访问 API 服务器接口的子集。