網站前後端分離問題：
例如首頁是由多個模組組成，每個模組有自己的API接口，
前端人員讓我把數據一次返回給他，我需要再對接口進行組合，
請問這樣好不好？還是他透過多次請求分別獲取數據好
網站前後端分離問題：
例如首頁是由多個模組組成，每個模組有自己的API接口，
前端人員讓我把數據一次返回給他，我需要再對接口進行組合，
請問這樣好不好？還是他透過多次請求分別獲取數據好
說個重一點的方案，但可能沒有回答你的問題。
依照大前端的概念，如果中間加上一個Node層，對前端可以完成服務端渲染，對後端可以整合API。而且這個由前端來維護，不求後端，自己折騰。 ：）
資源消耗相同或資源消耗比較小的情況下 一個介面能夠搞定的事不要寫兩個介面
Node，go等高並發的做api。最好不要一次發，從restful api來說這麼玩不好。等於後端隨著前端的變化而不斷變化，不適合解耦和模組化。前端可以做好緩存，減少交互，例如redux，資料的快取。不要每次都到後端拿數據，就是一次給數據也擋不住啥都到後端拿，也是大量交互。很多都拿到之後可先用緩存，有個時間間隔或用戶點了刷新之類的再去服務端拿資料。
一次好吧，畢竟 HTTP 請求還是越少越好吧，，你就多寫幾行程式碼的事吧
不同角色，看問題的角度是不同的。
站在前端角度，可能就是一個請求都回傳了，減少了 http 的請求，效能提高了，前端能就少發幾個請求。
站在後端角度，就是分模組寫接口，清晰明了。
我本身是後端，我的一般觀點就是【覺得合適，開發難度不大，不影響你】，就合併一起吧，在返回的數據裡，根據不同key 也可以做到模組的區分，後期增加、刪除模組，也很容易。
大家的角色不同，沒必要非要爭對錯，這種沒有絕對，沒有絕對適合任何情況的解決方案，靈活處理。
當然，你也可以堅持。
如果回傳的數據很多，例如幾十頁的分頁數據，這個肯定需要依據分頁來獲得數據。
如果返回的資料不多，不會因返回的資料多而對效能造成影響（即可以忽略不計的影響），那麼建議一次返回，因為這樣可能大大減少了前端的工作量，同時因為請求資料的次數不是很頻繁，對表現也是有好處的。
你們不會用HTTP 2.0嗎？
HTTP 2.0 多次請求，一次發送，你值得擁有。
還有，如果後台是RESTful的，組合介面破壞了邏輯，十分傷。如果前端不知道RESTful的話，把他開了吧。
額，新開一個接口，將不同模組資料依要求組合下就好了。反正不同模組都封裝好了，呼叫下就好了，這個介面也專門用來做這個用途，不要混用。
