產品后臺實現后,總要對應不同的客戶端。例如我司產品目前就有 Android App、iOS App、普通瀏覽器、App 內置 WebView、微信等具有自己 js api 的特殊瀏覽器等客戶端。
這些客戶端為了實現相應功能,請求的數據格式可能也會不同,比如 html、json、file 等等。
當然除去部分專屬功能,后臺邏輯和業務基本都一樣,但表示層實現的區別如何卻關系到整個系統維護甚至團隊分工。
考慮常見的 http 方式請求(當然其他 WebService 等方式請求的后臺應該也大同小異):
http[s]://domain[/]path[?query][#fragment]
可以在以下三個級別進行區分。
domain
最高可以在站點級別進行區分,早年流行的 m.domain 就是這種思路,不過后來實現了響應式站點后,網頁部分就不需要單獨拆開了。當然現在多了 app 還可以 app.domain。
這個方案的好處就是不同站點拆的很獨立,人多的話分成幾組各自負責互不干擾,各自都能隨著產品經理的心情獨立發展出千奇百怪的樣子。
缺點也很明顯,SEO 被分流不說,還增加了開發、維護成本,人不夠多時會感覺很麻煩。
path
接下來可以考慮在路徑上區別,比如常見的 ajaxPath 命名規則就是這種思路,把請求的數據格式按照命名進行區別,app 也可以 appPath。
這個方案的好處是同一個站點的基礎上保持了不同的入口,兼具維護成本低和清晰獨立的優點。
缺點是邏輯仍然不容易聚合,例如為了代碼可讀性,可能所有 get/post、ajax 或 app 方法分別在不同的單獨文件,或者在同一個文件的不同區域。有時候一處發現 bug 可能別處也需要修改,代碼量大時找起來還是比較麻煩。
header
再接下來可以考慮在 header 信息上區別,比如增加自定義 header 或者修改 user agent 字段。
這個方案好處是同一入口,所以邏輯高度內聚,只需根據 header 信息不同做不同的特殊處理。
缺點也是同一個入口,靈活度差。如果遇上接口改動,需要考慮 app 舊版本兼容性會比較麻煩。
_ *query 也可以達到區分的目的,不過本質上和 header 的效果都是同一個入口,加上濫用參數的嫌疑所以只列出了 header _
以上三種方法也可以根據產品特性及團隊資源混合使用。