javascript - 網站前後端分離問題,API編寫

網站前後端分離問題：
例如 首頁是由多個模組組成，每個模組有自己的API介面，
前端人員讓我把資料一次返回給他，我需要再對介面進行組合，
請問這樣好不好？還是他通過多次請求分別擷取資料好

回複內容：

網站前後端分離問題：
例如 首頁是由多個模組組成，每個模組有自己的API介面，
前端人員讓我把資料一次返回給他，我需要再對介面進行組合，
請問這樣好不好？還是他通過多次請求分別擷取資料好

說個重一點的方案，但可能沒有回答你的問題。

按照大前端的概念，如果中間加一個Node層，對前端可以完成服務端渲染，對後端可以整合API。而且這個由前端來維護，不求後端，自己折騰。 ：）

資源消耗相同或資源消耗比較小的情況下 一個介面能夠搞定的事不要寫兩個介面

Node，go等高並發的做api。最好不要一次發，從restful api來說這麼玩不好。等於後端隨著前端的變化在不斷變化，不適合解耦和模組化。前端可以做好緩衝，減少互動，比如redux，資料的緩衝。不要每次都到後端拿資料，就是一次給資料也擋不住啥都到後端拿，也是大量互動。很多都拿到之後可先用緩衝，有個時間間隔或者使用者點了重新整理之類的再去服務端拿資料。

一次好吧，畢竟 HTTP 要求還是越少越好吧，，你就多寫幾行代碼的事吧

不同角色，看問題的角度是不同的。
站在前端角度，可能就是一個請求都返回了，減少了 http 的請求，效能提高了，前端能就少發幾個請求。
站在後端角度，就是分模組寫介面，清晰明了。

我本身是後端，我的一般觀點就是 【覺得合適，開發難度不大，不影響你】，就合并一起吧，在返回的資料裡，根據不同 key 也可以做到模組的區分，後期增加、刪除模組，也很容易。

大家的角色不同，沒必要非要爭對錯，這種沒有絕對，沒有絕對適合任何情況的解決方案，靈活處理。

當然，你也可以堅持。

如果返回的資料很多，比如幾十頁的分頁資料，這個肯定需要依據分頁來獲得資料。

如果返回的資料不多，不會因返回的資料多而對效能造成影響（即可以忽略不計的影響），那麼建議一次返回，因為這樣可能大大減少了前端的工作量，同時因為請求資料的次數不是很頻繁，對效能也是有好處的。

你們不會用HTTP 2.0嗎？

HTTP 2.0 多次請求，一次發送，你值得擁有。

還有，如果後台是RESTful的，組合介面破壞了邏輯，十分傷。如果前端不知道RESTful的話，把他開了吧。

額，新開一個介面，將不同模組資料按要求組合下就好了。反正不同模組都封裝好了，調用下就好了，這個介面也專門用來做這個用途，不要混用。

