產(chǎn)品后臺(tái)實(shí)現(xiàn)后借尿，總要對(duì)應(yīng)不同的客戶端国旷。例如我司產(chǎn)品目前就有 Android App矛物、iOS App、普通瀏覽器跪但、App 內(nèi)置 WebView履羞、微信等具有自己 js api 的特殊瀏覽器等客戶端。
這些客戶端為了實(shí)現(xiàn)相應(yīng)功能屡久，請(qǐng)求的數(shù)據(jù)格式可能也會(huì)不同忆首，比如 html、json被环、file 等等糙及。
當(dāng)然除去部分專(zhuān)屬功能，后臺(tái)邏輯和業(yè)務(wù)基本都一樣筛欢，但表示層實(shí)現(xiàn)的區(qū)別如何卻關(guān)系到整個(gè)系統(tǒng)維護(hù)甚至團(tuán)隊(duì)分工浸锨。
考慮常見(jiàn)的 http 方式請(qǐng)求（當(dāng)然其他 WebService 等方式請(qǐng)求的后臺(tái)應(yīng)該也大同小異）：
http[s]://domain[/]path[?query][#fragment]
可以在以下三個(gè)級(jí)別進(jìn)行區(qū)分。
domain
最高可以在站點(diǎn)級(jí)別進(jìn)行區(qū)分版姑，早年流行的 m.domain 就是這種思路柱搜，不過(guò)后來(lái)實(shí)現(xiàn)了響應(yīng)式站點(diǎn)后，網(wǎng)頁(yè)部分就不需要單獨(dú)拆開(kāi)了剥险。當(dāng)然現(xiàn)在多了 app 還可以 app.domain聪蘸。
這個(gè)方案的好處就是不同站點(diǎn)拆的很獨(dú)立，人多的話分成幾組各自負(fù)責(zé)互不干擾表制，各自都能隨著產(chǎn)品經(jīng)理的心情獨(dú)立發(fā)展出千奇百怪的樣子宇姚。
缺點(diǎn)也很明顯，SEO 被分流不說(shuō)夫凸，還增加了開(kāi)發(fā)浑劳、維護(hù)成本，人不夠多時(shí)會(huì)感覺(jué)很麻煩夭拌。
path
接下來(lái)可以考慮在路徑上區(qū)別魔熏，比如常見(jiàn)的 ajaxPath 命名規(guī)則就是這種思路，把請(qǐng)求的數(shù)據(jù)格式按照命名進(jìn)行區(qū)別鸽扁，app 也可以 appPath蒜绽。
這個(gè)方案的好處是同一個(gè)站點(diǎn)的基礎(chǔ)上保持了不同的入口，兼具維護(hù)成本低和清晰獨(dú)立的優(yōu)點(diǎn)桶现。
缺點(diǎn)是邏輯仍然不容易聚合躲雅，例如為了代碼可讀性，可能所有 get/post骡和、ajax 或 app 方法分別在不同的單獨(dú)文件相赁，或者在同一個(gè)文件的不同區(qū)域相寇。有時(shí)候一處發(fā)現(xiàn) bug 可能別處也需要修改，代碼量大時(shí)找起來(lái)還是比較麻煩钮科。
header
再接下來(lái)可以考慮在 header 信息上區(qū)別唤衫，比如增加自定義 header 或者修改 user agent 字段。
這個(gè)方案好處是同一入口绵脯，所以邏輯高度內(nèi)聚佳励，只需根據(jù) header 信息不同做不同的特殊處理。
缺點(diǎn)也是同一個(gè)入口蛆挫，靈活度差赃承。如果遇上接口改動(dòng)，需要考慮 app 舊版本兼容性會(huì)比較麻煩悴侵。
_ *query 也可以達(dá)到區(qū)分的目的楣导，不過(guò)本質(zhì)上和 header 的效果都是同一個(gè)入口，加上濫用參數(shù)的嫌疑所以只列出了 header _
以上三種方法也可以根據(jù)產(chǎn)品特性及團(tuán)隊(duì)資源混合使用畜挨。
