來(lái)討論下你們的api是怎么寫(xiě)的？

1. 盡量遵循 RESTful ，但是也要和實(shí)際業(yè)務(wù)需求結(jié)合，靈活應(yīng)變。
2. 首頁(yè)一般是聚合頁(yè)，數(shù)據(jù)來(lái)源較多。通常：按功能分，按緩存分。也不會(huì)全部放在一個(gè)接口里。
3. 靜態(tài)內(nèi)容全部走CDN，減少 PHP 服務(wù)器的壓力，一個(gè)頁(yè)面調(diào)用的 API 接口最多三個(gè)。

脫離需求談規(guī)范，都是不對(duì)的。正所謂分久必合，合久必分：

在之前，前端的并發(fā)能力有限，減少請(qǐng)求次數(shù)是性能優(yōu)化的一個(gè)重要手段，那你只能妥協(xié)。

現(xiàn)在，你可以在架構(gòu)上嘗試解決，比如http2的合并請(qǐng)求，又或者用api網(wǎng)關(guān)合并，那就能同時(shí)滿足后端保持單一職責(zé)，前端減少請(qǐng)求。

總體的趨勢(shì)，看起來(lái)是“分”的越來(lái)越徹底，比如從微服務(wù)到FaSS，但那只是把“合”的部分放在“平臺(tái)”來(lái)解決

• 接口原則的話，當(dāng)然必須是以業(yè)務(wù)需要為核心前提，規(guī)則的話 RESTful 你可以區(qū)了解下
• 首頁(yè)的話，看什么樣的網(wǎng)站了，如果數(shù)據(jù)量不大那一次給完數(shù)據(jù)也行，數(shù)據(jù)量大的話我認(rèn)為還是和前端同事商量下怎么去優(yōu)化吧，有些東西能靜態(tài)化的靜態(tài)化，能緩存的緩存
• 分拆和減少 HTTP 請(qǐng)求這件事情還是那句話，根據(jù)自身的業(yè)務(wù)好好考慮那些請(qǐng)求可以合并，哪些又可以拆分，核心還是那句話，怎么權(quán)衡要看具體的業(yè)務(wù)場(chǎng)景的，技術(shù)脫離了業(yè)務(wù)場(chǎng)景就沒(méi)意義了