产品后台实现后，总要对应不同的客户端。例如我司产品目前就有 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 _
以上三种方法也可以根据产品特性及团队资源混合使用。
