亚洲在线久爱草,狠狠天天香蕉网,天天搞日日干久草,伊人亚洲日本欧美

為了賬號安全,請及時綁定郵箱和手機立即綁定
已解決430363個問題,去搜搜看,總會有你想問的

來討論下你們的api是怎么寫的?

來討論下你們的api是怎么寫的?

呼啦一陣風 2019-05-23 18:43:23
我的理解我寫了快幾年的api了,一直都遵循著,一個api接口完成一個事情的規則我可能還是更多的傾向于一個接口完成一個事情!我的困惑現在的有些app首頁內容量很大,有的人主張首頁一個api返回所有數據,因為他說要減少請求的次數,以減少耗電等看一本關于優化的書籍的時候,也的卻有提到減少網絡請求的優化方式基于1的困惑,我的理解假如有一張表,或者數據產生堵塞,會影響整個app首頁的加載,會不會更不好。我想請教或者討論的你們的項目,你的接口遵循的是什么規則首頁的問題,你們是如何處理的對于接口分拆和減少網絡請求你們是怎么權衡的
查看完整描述

2 回答

?
慕妹3242003

TA貢獻1824條經驗 獲得超6個贊

盡量遵循RESTful,但是也要和實際業務需求結合,靈活應變。
首頁一般是聚合頁,數據來源較多。通常:按功能分,按緩存分。也不會全部放在一個接口里。
靜態內容全部走CDN,減少PHP服務器的壓力,一個頁面調用的API接口最多三個。
                            
查看完整回答
反對 回復 2019-05-23
?
縹緲止盈

TA貢獻2041條經驗 獲得超4個贊

脫離需求談規范,都是不對的。正所謂分久必合,合久必分:
在之前,前端的并發能力有限,減少請求次數是性能優化的一個重要手段,那你只能妥協。
現在,你可以在架構上嘗試解決,比如http2的合并請求,又或者用api網關合并,那就能同時滿足后端保持單一職責,前端減少請求。
總體的趨勢,看起來是“分”的越來越徹底,比如從微服務到FaSS,但那只是把“合”的部分放在“平臺”來解決
                            
查看完整回答
反對 回復 2019-05-23
  • 2 回答
  • 0 關注
  • 299 瀏覽
慕課專欄
更多

添加回答

舉報

0/150
提交
取消
微信客服

購課補貼
聯系客服咨詢優惠詳情

幫助反饋 APP下載

慕課網APP
您的移動學習伙伴

公眾號

掃描二維碼
關注慕課網微信公眾號