誰與API（REST）通話？ Web客戶端與服務器？

Question

在我的應用程序架構，我有以下組成部分：

• Mobile客戶端
• API（REST）
• Web客戶端
• Web服務器（Web客戶機）

手機正在與api交談，這很明顯。 但是，我想知道哪個Web組件應該與api對話。

在開始的時候，我開始把它變成服務器端。然後我意識到服務器只是簡單地調用api，客戶端也可以這麼做 - 爲什麼不將這些調用委託給客戶端呢？那就是：

1. 要求：客戶端 - >服務器 - > API
2. 響應：API - >服務器 - >客戶端

我們得到：

1. 要求：客戶端 - > serevr + client-> api
2. response：server - > client，api - > client。

它的優點是我們的服務器必須減少網絡呼叫，從而減少帶寬。現在客戶端可能需要一點點增加的帶寬，但它不需要處理所有的用戶。另外，客戶端的整體加載時間不會增加（我認爲？），因爲客戶端必須等待api響應;無論是否通過服務器。

因此，目前，我的網絡客戶端正在直接與網絡通話。 但是，它感覺有點奇怪，特別是關於認證。

1. 這是正確的選擇嗎？
2. 兩者之間有更好的選擇嗎？
3. 是否有更多的優點或缺點這種選擇

Answer 1

配置您的客戶端通過一箇中間的Web服務器進行操作是個不錯的設置，可能最好。

如果您的Web服務器僅向後端提供靜態內容和管道API請求，那麼它可能支持許多API實例的流量。這意味着您可以通過擁有多個API實例來增加容量，並讓Web服務器負載均衡。

此外，您可以通過在內部網絡上訪問API並通過可公開訪問的Web服務器路由調用來減少主機環境的攻擊面。這樣你也可以選擇發佈多少API接口。

最後，您可以在一個地方處理身份驗證。如果Web服務器處理認證，並且在將每個呼叫路由到API服務器之前檢查每個呼叫的認證，那麼您的API服務器只需要擔心一件事（這假設您的API服務器只能在您的內部網絡上訪問，如上所述）。您甚至可以在此處實施身份驗證方案，以便用戶只能訪問API服務器接口的子集。

Answer 2

這個問題已經有一段時間了，但我會添加一個答案只是作爲參考。

客戶端渲染會影響初始加載，因爲客戶端（本例中爲瀏覽器）首先必須接收來自Web服務器的所有JavaScript代碼，然後再向API服務器發出另一個請求以獲取數據。

另一個問題是SEO。網絡爬蟲不處理JavaScript呈現（Google是唯一聲稱有關此事的改進）。他們只是希望html能夠響應他們的請求，而沒有數據的頁面對於索引目的來說毫無用處。

爲了緩解這個問題，可以採取混合的方法，即所謂的通用（以前稱爲同構）應用程序。這是可以在客戶端和服務器上呈現的應用程序。它具有客戶端應用程序的優勢，但服務器端呈現將提供給網絡爬蟲並負責第一次加載。現在普遍的方法是非常可行的，因爲JavaScript可以在服務器和客戶端上運行。因此，大部分代碼都可以共享。

airbnb中有一篇非常好的博客文章談論它：http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/