產品后臺實現后，總要對應不同的客戶端。例如我司產品目前就有 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 _
以上三種方法也可以根據產品特性及團隊資源混合使用。
