為什么不行,？
在設計通用 API 時,，你會遇到一系列鬧心的問題：
如何預測和支持所有可能的工作流程,？
如何避免某些蹩腳的工作流程中的 N+1 問題？
如何測試每個可能出現(xiàn)的請求的功能,、性能和安全性,？
如何在不破壞現(xiàn)有工作流程的情況下修改某個 API？
如何根據內部和社區(qū)的需求,，劃分修改 API 的優(yōu)先級,？
如何完善文檔，以方便各方順利完成工作,？
從前端的角度來看,，還有更多問題需要考慮：
如何收集渲染頁面所需的所有數(shù)據？
如何優(yōu)化發(fā)往多個端點的多個請求,？
如何避免以預期之外的方式使用 API 數(shù)據字段,？
如何權衡新功能與構建新 API 的成本？
如果只是為了前端而構建后端,，你需要考慮這么多問題嗎,？你需要考慮每一種可能的工作流程，避免 N+1 請求問題,，測試每個請求配置,？還是應該拒絕某些功能，因為你非常清楚每個頁面需要呈現(xiàn)什么,？看到這里,，你可能明白我想說什么了。
建議
我建議不要將前端視為某個通用 API 的客戶端,，應將其視為應用的一半,。
假設你可以把整個頁面所需的 JSON 全部發(fā)送給前端。那么只需要創(chuàng)建一個端點/page/a,，然后渲染/page/a的整個JSON就可以了,。而且，每個頁面都應該采用相同的做法。不要強迫前端開發(fā)人員發(fā)送一堆單獨的請求來渲染復雜的頁面,。不要人為地制造的限制,。
這個 JSON 需要負責渲染整個頁面。不要渲染抽象模型和集合,，而是應該渲染具體的方框,、小節(jié)、段落,、列表等。渲染可視化頁面結構,。
{
“section1”: {
“topBoxTitle”: “Foo”,
“l(fā)eftBoxTitle”: “Bar”,
“l(fā)inkToClose”: “https://…”
},
“section2”: {
…
}
}
這與服務器驅動 UI 類似,，但不完全相同。我們可以稱之為服務器通知 UI,。
哪種方法更好,？
看到上面那些繁雜的考慮事項了嗎？設計前端專用的 API 就不會為這些問題鬧心了,。
你可以自由決定：我想要一個頁面A,。然后只需在后端和前端實現(xiàn)頁面A。非常簡單,。
我們無需再考慮：必須引入哪些 API 工作流程,，才能成功地渲染這個頁面？頁面 A 的實現(xiàn)非常簡單,，只需要實現(xiàn)頁面本身的功能,。你可以完整地測試頁面A，檢查 Bug,、安全和性能問題,。你甚至可以通過一個大型 SQL 查詢語句，獲取頁面 A 所需的所有數(shù)據,。你可以將頁面 A 的整個 JSON 放入緩存,。
前端非常清楚頁面 A 中每個字段的用途。這些字段沒有歧義,，它們準確地代表了前端的需求,。
當需要修改頁面 A 時，你只需徑直打開頁面 A,，完成修改就行了,，無需花大把時間開會討論如何修改后端 API 才能實現(xiàn)前端的變更。這個 API 只服務于頁面 A,，不需要精心設計服務多個請求,。只有這樣，我們才能擺脫自我強加的限制。
此外,，業(yè)務邏輯可以全部交由后端負責,，無需在前端和后端之間的分工上浪費精力。前端可以專心呈現(xiàn)頁面,，而后端則可以專心實現(xiàn)前端所需的內容,。目標明確，不是嗎,？
如何實踐,？
我曾在多個生產項目中嘗試過這種做法。其中有一個是個人的項目,，還有一個是在公司現(xiàn)有項目的基礎之上進行的重構,。我們整個團隊都參與了那個項目，而且效果很好,。我們遇到的唯一問題就是,，前端的工作越來越無聊，因為幾乎所有的業(yè)務邏輯都由后端負責,。同時,，后端團隊也沒有感覺到太大壓力。而且大多數(shù)時候,，我們談論的都是業(yè)務相關的內容,，而不是代碼。
當然,，很多人不太贊同這種做法,，常見的反對意見如下。
我希望前端自由（或者,，我希望前端解耦）,！
不要自欺欺人了，通用 API 并沒有賦予前端真正的自由,。為了渲染一個頁面,，需要發(fā)送 7 個請求，這不是自由,。這是為了滿足基本的要求而作繭自縛,。一旦需求發(fā)生變化，后端也必然需要變更,。這樣的自由都是偶然的,，而且大多是發(fā)生在錯誤的地方。
如果真的想讓前端團隊自由,，直接在 Postgres 上安裝一個 GraphQL 包裝器,，就可以了,。
我們本來就需要通用API，這樣不是一箭雙雕嗎,？
不,，其實你沒有必要公開這些 API。真正到了發(fā)布的時候,，你可能會想：“也許我不應該公開這些API”,。通用 API 與前端專用API 的變更有非常大的不同。公開 API 需要支持客戶端的工作流程,。而前端專用 API 可以隨意變更,。沒有困難，就不要制造困難了,。
如果給每個頁面構建JSON,，那么邏輯代碼該如何重用？現(xiàn)在的 CRUD 控制器中大量的邏輯代碼都是重用的,！
如果編程語言允許，完全可以重用邏輯,。你可以使用 mixins,、組合、繼承,，以及其他任何方式,。如果能建立良好的抽象，就像樂高積木一樣,，只需要將積木搭建起來就可以了,。
通用 API 可以在移動應用中重用！
通常移動應用都有不同的頁面,，其中包含的信息和結構不同,，變更的原因也不同。專門針對各個頁面構建一個后端,，可以節(jié)省很多時間,。
如果頁面需要部分XHR 更新怎么辦？始終返回整個頁面嗎,？
創(chuàng)建一個只返回特定數(shù)據的端點也是沒問題的,。你完全可以針對頁面特定部分的數(shù)據建立一個端點。在頁面最初加載的時候渲染 React 組件,，然后通過調用這些端點的 XHR 更新各個組件,。但是，只有某些頁面有這樣的需求時,，才有必要引入這些端點,。這是特殊的處理,，一般不需要實現(xiàn)。
我的前端是一個SPA,，只需要一部分數(shù)據,，不需要整個頁面。
即便是部分數(shù)據,，也可以作為部分頁面結構提供給前端,，不需要作為通用資源。只要后端能夠滿足前端的需求即可,。
我正在構建一個站點構建器,，所以前端實際上只是站點構建器 API 的測試。
這是一種正確的用法,，加油,！
你有數(shù)據支持這種做法嗎？
我希望能夠收集到這樣的數(shù)據,，然而,，我們很難準確地衡量。誰會同時針對一個軟件長期維護兩個架構,，然后比較二者的效果,？本文表達的只是我個人的經歷。
