我的理解
我寫了快幾年的api了，一直都遵循著，一個api接口完成一個事情的規(guī)則
我可能還是更多的傾向于一個接口完成一個事情！
我的困惑
現(xiàn)在的有些app首頁內(nèi)容量很大，有的人主張首頁一個api返回所有數(shù)據(jù)，因為他說要減少請求的次數(shù)，以減少耗電等
看一本關(guān)于優(yōu)化的書籍的時候，也的卻有提到減少網(wǎng)絡(luò)請求的優(yōu)化方式
基于1的困惑，我的理解假如有一張表，或者數(shù)據(jù)產(chǎn)生堵塞，會影響整個app首頁的加載，會不會更不好。
我想請教或者討論的
你們的項目，你的接口遵循的是什么規(guī)則
首頁的問題，你們是如何處理的
對于接口分拆和減少網(wǎng)絡(luò)請求你們是怎么權(quán)衡的
3 回答
牧羊人nacy
TA貢獻1862條經(jīng)驗 獲得超7個贊
- 盡量遵循
RESTful，但是也要和實際業(yè)務(wù)需求結(jié)合，靈活應(yīng)變。 - 首頁一般是聚合頁，數(shù)據(jù)來源較多。通常：按功能分，按緩存分。也不會全部放在一個接口里。
- 靜態(tài)內(nèi)容全部走CDN，減少 PHP 服務(wù)器的壓力，一個頁面調(diào)用的 API 接口最多三個。
尚方寶劍之說
TA貢獻1788條經(jīng)驗 獲得超4個贊
脫離需求談規(guī)范，都是不對的。正所謂分久必合，合久必分：
在之前，前端的并發(fā)能力有限，減少請求次數(shù)是性能優(yōu)化的一個重要手段，那你只能妥協(xié)。
現(xiàn)在，你可以在架構(gòu)上嘗試解決，比如http2的合并請求，又或者用api網(wǎng)關(guān)合并，那就能同時滿足后端保持單一職責(zé)，前端減少請求。
總體的趨勢，看起來是“分”的越來越徹底，比如從微服務(wù)到FaSS，但那只是把“合”的部分放在“平臺”來解決
江戶川亂折騰
TA貢獻1851條經(jīng)驗 獲得超5個贊
- 接口原則的話，當(dāng)然必須是以業(yè)務(wù)需要為核心前提，規(guī)則的話
RESTful你可以區(qū)了解下 - 首頁的話，看什么樣的網(wǎng)站了，如果數(shù)據(jù)量不大那一次給完數(shù)據(jù)也行，數(shù)據(jù)量大的話我認(rèn)為還是和前端同事商量下怎么去優(yōu)化吧，有些東西能靜態(tài)化的靜態(tài)化，能緩存的緩存
- 分拆和減少
HTTP請求這件事情還是那句話，根據(jù)自身的業(yè)務(wù)好好考慮那些請求可以合并，哪些又可以拆分，核心還是那句話，怎么權(quán)衡要看具體的業(yè)務(wù)場景的，技術(shù)脫離了業(yè)務(wù)場景就沒意義了
添加回答
舉報
0/150
提交
取消