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