谁与API（REST）通话？ Web客户端与服务器？
在我的应用程序架构，我有以下组成部分：谁与API（REST）通话？ Web客户端与服务器？
- Mobile客户端
- API（REST）
- Web客户端
- Web服务器（Web客户机）
手机正在与api交谈，这很明显。 但是，我想知道哪个Web组件应该与api对话。
在开始的时候，我开始把它变成服务器端。然后我意识到服务器只是简单地调用api，客户端也可以这么做 - 为什么不将这些调用委托给客户端呢？那就是：
- 要求：客户端 - >服务器 - > API
- 响应：API - >服务器 - >客户端
我们得到：
- 要求：客户端 - > serevr + client-> api
- response：server - > client，api - > client。
它的优点是我们的服务器必须减少网络呼叫，从而减少带宽。现在客户端可能需要一点点增加的带宽，但它不需要处理所有的用户。另外，客户端的整体加载时间不会增加（我认为？），因为客户端必须等待api响应;无论是否通过服务器。
因此，目前，我的网络客户端正在直接与网络通话。 但是，它感觉有点奇怪，特别是关于认证。
- 这是正确的选择吗？
- 两者之间有更好的选择吗？
- 是否有更多的优点或缺点这种选择
配置您的客户端通过一个中间的Web服务器进行操作是个不错的设置，可能最好。
如果您的Web服务器仅向后端提供静态内容和管道API请求，那么它可能支持许多API实例的流量。这意味着您可以通过拥有多个API实例来增加容量，并让Web服务器负载均衡。
此外，您可以通过在内部网络*问API并通过可公开访问的Web服务器路由调用来减少主机环境的攻击面。这样你也可以选择发布多少API接口。
最后，您可以在一个地方处理身份验证。如果Web服务器处理认证，并且在将每个呼叫路由到API服务器之前检查每个呼叫的认证，那么您的API服务器只需要担心一件事（这假设您的API服务器只能在您的内部网络*问，如上所述）。您甚至可以在此处实施身份验证方案，以便用户只能访问API服务器接口的子集。
这个问题已经有一段时间了，但我会添加一个答案只是作为参考。
客户端渲染会影响初始加载，因为客户端（本例中为浏览器）首先必须接收来自Web服务器的所有JavaScript代码，然后再向API服务器发出另一个请求以获取数据。
另一个问题是SEO。网络爬虫不处理JavaScript呈现（Google是唯一声称有关此事的改进）。他们只是希望html能够响应他们的请求，而没有数据的页面对于索引目的来说毫无用处。
为了缓解这个问题，可以采取混合的方法，即所谓的通用（以前称为同构）应用程序。这是可以在客户端和服务器上呈现的应用程序。它具有客户端应用程序的优势，但服务器端呈现将提供给网络爬虫并负责第一次加载。现在普遍的方法是非常可行的，因为JavaScript可以在服务器和客户端上运行。因此，大部分代码都可以共享。
airbnb中有一篇非常好的博客文章谈论它：http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/