為什么不行？

　　在設(shè)計(jì)通用 API 時(shí)，你會(huì)遇到一系列鬧心的問題：

　　如何預(yù)測(cè)和支持所有可能的工作流程？

　　如何避免某些蹩腳的工作流程中的 N+1 問題？

　　如何測(cè)試每個(gè)可能出現(xiàn)的請(qǐng)求的功能、性能和安全性？

　　如何在不破壞現(xiàn)有工作流程的情況下修改某個(gè) API？

　　如何根據(jù)內(nèi)部和社區(qū)的需求，劃分修改 API 的優(yōu)先級(jí)？

　　如何完善文檔，以方便各方順利完成工作？

　　從前端的角度來看，還有更多問題需要考慮：

　　如何收集渲染頁面所需的所有數(shù)據(jù)？

　　如何優(yōu)化發(fā)往多個(gè)端點(diǎn)的多個(gè)請(qǐng)求？

　　如何避免以預(yù)期之外的方式使用 API 數(shù)據(jù)字段？

　　如何權(quán)衡新功能與構(gòu)建新 API 的成本？

　　如果只是為了前端而構(gòu)建后端，你需要考慮這么多問題嗎？你需要考慮每一種可能的工作流程，避免 N+1 請(qǐng)求問題，測(cè)試每個(gè)請(qǐng)求配置？還是應(yīng)該拒絕某些功能，因?yàn)槟惴浅Ｇ宄總€(gè)頁面需要呈現(xiàn)什么？看到這里，你可能明白我想說什么了。

　　建議

　　我建議不要將前端視為某個(gè)通用 API 的客戶端，應(yīng)將其視為應(yīng)用的一半。

　　假設(shè)你可以把整個(gè)頁面所需的 JSON 全部發(fā)送給前端。那么只需要?jiǎng)?chuàng)建一個(gè)端點(diǎn)/page/a，然后渲染/page/a的整個(gè)JSON就可以了。而且，每個(gè)頁面都應(yīng)該采用相同的做法。不要強(qiáng)迫前端開發(fā)人員發(fā)送一堆單獨(dú)的請(qǐng)求來渲染復(fù)雜的頁面。不要人為地制造的限制。

　　這個(gè) JSON 需要負(fù)責(zé)渲染整個(gè)頁面。不要渲染抽象模型和集合，而是應(yīng)該渲染具體的方框、小節(jié)、段落、列表等。渲染可視化頁面結(jié)構(gòu)。

　　{

　　“section1”: {

　　“topBoxTitle”: “Foo”,

　　“l(fā)eftBoxTitle”: “Bar”,

　　“l(fā)inkToClose”: “https://…”

　　},

　　“section2”: {

　　…

　　}

　　}

　　這與服務(wù)器驅(qū)動(dòng) UI 類似，但不完全相同。我們可以稱之為服務(wù)器通知 UI。

　　哪種方法更好？

　　看到上面那些繁雜的考慮事項(xiàng)了嗎？設(shè)計(jì)前端專用的 API 就不會(huì)為這些問題鬧心了。

　　你可以自由決定：我想要一個(gè)頁面A。然后只需在后端和前端實(shí)現(xiàn)頁面A。非常簡(jiǎn)單。

　　我們無需再考慮：必須引入哪些 API 工作流程，才能成功地渲染這個(gè)頁面？頁面 A 的實(shí)現(xiàn)非常簡(jiǎn)單，只需要實(shí)現(xiàn)頁面本身的功能。你可以完整地測(cè)試頁面A，檢查 Bug、安全和性能問題。你甚至可以通過一個(gè)大型 SQL 查詢語句，獲取頁面 A 所需的所有數(shù)據(jù)。你可以將頁面 A 的整個(gè) JSON 放入緩存。

　　前端非常清楚頁面 A 中每個(gè)字段的用途。這些字段沒有歧義，它們準(zhǔn)確地代表了前端的需求。

　　當(dāng)需要修改頁面 A 時(shí)，你只需徑直打開頁面 A，完成修改就行了，無需花大把時(shí)間開會(huì)討論如何修改后端 API 才能實(shí)現(xiàn)前端的變更。這個(gè) API 只服務(wù)于頁面 A，不需要精心設(shè)計(jì)服務(wù)多個(gè)請(qǐng)求。只有這樣，我們才能擺脫自我強(qiáng)加的限制。

　　此外，業(yè)務(wù)邏輯可以全部交由后端負(fù)責(zé)，無需在前端和后端之間的分工上浪費(fèi)精力。前端可以專心呈現(xiàn)頁面，而后端則可以專心實(shí)現(xiàn)前端所需的內(nèi)容。目標(biāo)明確，不是嗎？

　　如何實(shí)踐？

　　我曾在多個(gè)生產(chǎn)項(xiàng)目中嘗試過這種做法。其中有一個(gè)是個(gè)人的項(xiàng)目，還有一個(gè)是在公司現(xiàn)有項(xiàng)目的基礎(chǔ)之上進(jìn)行的重構(gòu)。我們整個(gè)團(tuán)隊(duì)都參與了那個(gè)項(xiàng)目，而且效果很好。我們遇到的唯一問題就是，前端的工作越來越無聊，因?yàn)閹缀跛械臉I(yè)務(wù)邏輯都由后端負(fù)責(zé)。同時(shí)，后端團(tuán)隊(duì)也沒有感覺到太大壓力。而且大多數(shù)時(shí)候，我們談?wù)摰亩际菢I(yè)務(wù)相關(guān)的內(nèi)容，而不是代碼。

　　當(dāng)然，很多人不太贊同這種做法，常見的反對(duì)意見如下。

　　我希望前端自由（或者，我希望前端解耦）！

　　不要自欺欺人了，通用 API 并沒有賦予前端真正的自由。為了渲染一個(gè)頁面，需要發(fā)送 7 個(gè)請(qǐng)求，這不是自由。這是為了滿足基本的要求而作繭自縛。一旦需求發(fā)生變化，后端也必然需要變更。這樣的自由都是偶然的，而且大多是發(fā)生在錯(cuò)誤的地方。

　　如果真的想讓前端團(tuán)隊(duì)自由，直接在 Postgres 上安裝一個(gè) GraphQL 包裝器，就可以了。

　　我們本來就需要通用API，這樣不是一箭雙雕嗎？

　　不，其實(shí)你沒有必要公開這些 API。真正到了發(fā)布的時(shí)候，你可能會(huì)想：“也許我不應(yīng)該公開這些API”。通用 API 與前端專用API 的變更有非常大的不同。公開 API 需要支持客戶端的工作流程。而前端專用 API 可以隨意變更。沒有困難，就不要制造困難了。

　　如果給每個(gè)頁面構(gòu)建JSON，那么邏輯代碼該如何重用？現(xiàn)在的 CRUD 控制器中大量的邏輯代碼都是重用的！

　　如果編程語言允許，完全可以重用邏輯。你可以使用 mixins、組合、繼承，以及其他任何方式。如果能建立良好的抽象，就像樂高積木一樣，只需要將積木搭建起來就可以了。

　　通用 API 可以在移動(dòng)應(yīng)用中重用！

　　通常移動(dòng)應(yīng)用都有不同的頁面，其中包含的信息和結(jié)構(gòu)不同，變更的原因也不同。專門針對(duì)各個(gè)頁面構(gòu)建一個(gè)后端，可以節(jié)省很多時(shí)間。

　　如果頁面需要部分XHR 更新怎么辦？始終返回整個(gè)頁面嗎？

　　創(chuàng)建一個(gè)只返回特定數(shù)據(jù)的端點(diǎn)也是沒問題的。你完全可以針對(duì)頁面特定部分的數(shù)據(jù)建立一個(gè)端點(diǎn)。在頁面最初加載的時(shí)候渲染 React 組件，然后通過調(diào)用這些端點(diǎn)的 XHR 更新各個(gè)組件。但是，只有某些頁面有這樣的需求時(shí)，才有必要引入這些端點(diǎn)。這是特殊的處理，一般不需要實(shí)現(xiàn)。

　　我的前端是一個(gè)SPA，只需要一部分?jǐn)?shù)據(jù)，不需要整個(gè)頁面。

　　即便是部分?jǐn)?shù)據(jù)，也可以作為部分頁面結(jié)構(gòu)提供給前端，不需要作為通用資源。只要后端能夠滿足前端的需求即可。

　　我正在構(gòu)建一個(gè)站點(diǎn)構(gòu)建器，所以前端實(shí)際上只是站點(diǎn)構(gòu)建器 API 的測(cè)試。

　　這是一種正確的用法，加油！

　　你有數(shù)據(jù)支持這種做法嗎？

　　我希望能夠收集到這樣的數(shù)據(jù)，然而，我們很難準(zhǔn)確地衡量。誰會(huì)同時(shí)針對(duì)一個(gè)軟件長期維護(hù)兩個(gè)架構(gòu)，然后比較二者的效果？本文表達(dá)的只是我個(gè)人的經(jīng)歷。