在我的应用架构中，我有以下组件:
- 移动客户端
- API(休息)
- 网络客户端
- 网络服务器(用于网络客户端)
手机正在与 API 对话，这是显而易见的。 但是，我想知道哪一个 Web 组件应该与 api 通信。
一开始，我开始将其制作为服务器端。然后我意识到服务器只是调用 api，客户端也可以这样做 - 那么为什么不将这些调用委托(delegate)给客户端呢？即:
- 请求:客户端 -> 服务器 -> API
- 响应:api -> 服务器 -> 客户端
我们得到:
- 请求:客户端 -> serevr + 客户端 -> api
- 响应:服务器 -> 客户端，API -> 客户端。
它的优点是我们的服务器必须进行更少的网络调用，从而减少带宽。现在客户端可能需要增加一点带宽，但不需要处理所有用户。另外，客户端的整体加载时间并没有增加(我认为？)，因为客户端无论如何都必须等待 api 响应；无论是否通过服务器。
因此，目前，我的网络客户端正在直接与网络对话。 然而，感觉有点奇怪，特别是在身份验证方面。
- 这是正确的选择吗？
- 两者之间有更好的选择吗？
- 此选择有更多优点还是缺点
最佳答案
将您的客户端配置为通过中间 Web 服务器进行操作并不是一个糟糕的设置，而且可能更可取。
如果您的 Web 服务器仅提供静态内容并将 API 请求传送到后端，那么它可能可以支持许多 API 实例的流量。这意味着您可以通过拥有多个 API 实例来增加容量，并在它们之间实现 Web 服务器负载平衡。
此外，您可以通过仅在内部网络上访问 API 并通过可公开访问的 Web 服务器路由调用来减少托管环境的攻击面。这样您还可以选择要发布多少 API 接口(interface)。
最后，您可以在一个地方处理身份验证。如果身份验证由 Web 服务器处理，并且它在将每个调用路由到 API 服务器之前检查每个调用的身份验证，那么您的 API 服务器就少了一件需要担心的事情(这假设您的 API 服务器只能在您的内部网络上访问，如上所述) 。)您甚至可以在此时实现身份验证方案，以便用户只能访问 API 服务器接口(interface)的子集。
关于api - 谁与 API (REST) 对话？ Web 客户端与服务器？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26693511/