摘要：針對上面看到的問題，現(xiàn)在也有一些團隊在嘗試前后端之間加一個中間層比如淘寶的。淘寶有很多類似的文章，這里不贅述。淘寶團隊做了兩套接口文檔的維護工具，以及，不知道有沒有對外開放，兩個東西都是基于的一個嘗試，各有優(yōu)劣。

原文出處： 小胡子哥的博客（@Barret李靖）

前后端分工協(xié)作是一個老生常談的大話題，很多公司都在嘗試用工程化的方式去提升前后端之間交流的效率，降低溝通成本，并且也開發(fā)了大量的工具。但是幾乎沒有一種方式是令雙方都很滿意的。事實上，也不可能讓所有人都滿意。根本原因還是前后端之間的交集不夠大，交流的核心往往只限于接口及接口往外擴散的一部分。這也是為什么很多公司在招聘的時候希望前端人員熟練掌握一門后臺語言，后端同學了解前端的相關知識。

一、開發(fā)流程

前端切完圖，處理好接口信息，接著就是把靜態(tài)demo交給后臺去拼接，這是一般的流程。這種流程存在很多的缺陷。

后端同學對文件進行拆分拼接的時候，由于對前端知識不熟悉，可能會搞出一堆bug，到最后又需要前端同學幫助分析原因，而前端同學又不是特別了解后端使用的模板，造成尷尬的局面。

如果前端沒有使用統(tǒng)一化的文件夾結構，并且靜態(tài)資源（如圖片，css，js等）沒有剝離出來放到 CDN，而是使用相對路徑去引用，當后端同學需要對靜態(tài)資源作相關配置時，又得修改各個link，script標簽的src屬性，容易出錯。

接口問題
后端數(shù)據(jù)沒有準備好，前端需要自己模擬一套，成本高，如果后期接口有改變，自己模擬的那套數(shù)據(jù)又不行了。

后端數(shù)據(jù)已經(jīng)開發(fā)好，接口也準備好了，本地需要代理線上數(shù)據(jù)進行測試。這里有兩個費神的地方，一是需要代理，否則可能跨域，二是接口信息如果改動，后期接你項目的人需要改你的代碼，麻煩。

不方便控制輸出。為了讓首屏加載速度快一點，我們期望后端先吐出一點數(shù)據(jù)，剩下的才去 ajax 渲染，但讓后端吐出多少數(shù)據(jù)，我們不好控。

當然，存在的問題遠不止上面枚舉的這些，這種傳統(tǒng)的方式實在是不酷（Kimi 附身^_^）。還有一種開發(fā)流程，SPA（single page application），前后端職責相當清晰，后端給我接口，我全部用 ajax 異步請求，這種方式，在現(xiàn)代瀏覽器中可以使用 PJAX 稍微提高體驗，F(xiàn)acebook 早在三四年前對這種 SPA 的模式提出了一套解決方案，quickling+bigpipe，解決了 SEO 以及數(shù)據(jù)吐出過慢的問題。他的缺點也是十分明顯的：

頁面太重，前端渲染工作量也大
首屏還是慢
前后端模板復用不了
SEO 依然很狗血（quickling 架構成本高）
history 管理麻煩
問題多的已經(jīng)是無力吐槽了，當然他依然有自己的優(yōu)勢，咱們也不能一票否決。

針對上面看到的問題，現(xiàn)在也有一些團隊在嘗試前后端之間加一個中間層（比如淘寶UED的 MidWay ）。這個中間層由前端來控制。

JavaScript

+----------------+
|       F2E      |
+---↑--------↑---+
    |        | 
+---↓--------↓---+
|     Middle     |
+---↑--------↑---+
    |        |  
+---↓--------↓---+
|       R2E      |
+----------------+

+----------------+
|       F2E      |
+---↑--------↑---+
    |        | 
+---↓--------↓---+
|     Middle     |
+---↑--------↑---+
    |        |  
+---↓--------↓---+
|       R2E      |
+----------------+

中間層的作用就是為了更好的控制數(shù)據(jù)的輸出，如果用MVC模型去分析這個接口，R2E（后端）只負責 M（數(shù)據(jù)） 這部分，Middle（中間層）處理數(shù)據(jù)的呈現(xiàn)（包括 V 和 C）。淘寶UED有很多類似的文章，這里不贅述。

二、核心問題

上面提出了在業(yè)務中看到的常見的三種模式，問題的核心就是數(shù)據(jù)交給誰去處理。數(shù)據(jù)交給后臺處理，這是模式一，數(shù)據(jù)交給前端處理，這是模式二，數(shù)據(jù)交給前端分層處理，這是模式三。三種模式?jīng)]有優(yōu)劣之分，其使用還是得看具體場景。

既然都是數(shù)據(jù)的問題，數(shù)據(jù)從哪里來？這個問題又回到了接口。

接口文檔由誰來撰寫和維護？
接口信息的改動如何向前后端傳遞？
如何根據(jù)接口規(guī)范拿到前后端可用的測試數(shù)據(jù)？
使用哪種接口？JSON，JSONP？
JSONP 的安全性問題如何處理？
這一系列的問題一直困擾著奮戰(zhàn)在前線的前端工程師和后端開發(fā)者。淘寶團隊做了兩套接口文檔的維護工具，IMS以及DIP，不知道有沒有對外開放，兩個東西都是基于 JSON Schema 的一個嘗試，各有優(yōu)劣。JSON Schema 是對 JSON 的一個規(guī)范，類似我們在數(shù)據(jù)庫中創(chuàng)建表一樣，對每個字段做一些限制，這里也是一樣的原理，可以對字段進行描述，設置類型，限制字段屬性等。

接口文檔這個事情，使用 JSON Schema 可以自動化生產(chǎn)，所以只需編寫 JSON Schema 而不存在維護問題，在寫好的 Schema 中多加些限制性的參數(shù)，我們就可以直接根據(jù) Schema 生成 mock（測試） 數(shù)據(jù)。

mock 數(shù)據(jù)的外部調(diào)用，這倒是很好處理：

JavaScript

typeof callback === "function" && callback({
   json: "jsonContent"
})

typeof callback === "function" && callback({
   json: "jsonContent"
})

在請求的參數(shù)中加入 callback 參數(shù)，如 /mock/hashString?cb=callback，一般的 io(ajax) 庫都對異步數(shù)據(jù)獲取做了封裝，我們在測試的時候使用 jsonp，回頭上線，將 dataType 改成 json 就行了。

JavaScript

IO({
  url: "http://barretlee.com",
  dataType: "jsonp", //json
  success: function(){}
})

IO({
  url: "http://barretlee.com",
  dataType: "jsonp", //json
  success: function(){}
})

這里略微麻煩的是 POST 方法，jsonp 只能使用 get 方式插入 script 節(jié)點去請求數(shù)據(jù)，但是 POST，只能呵呵了。

這里的處理也有多重方式可以參考：

修改 Hosts，讓 mock 的域名指向開發(fā)域名
mock 設置 header 響應頭，Access-Allow-Origin-Control
對于如何拿到跨域的接口信息，我也給出幾個參考方案：

fiddler 替換包，好像是支持正則的，感興趣的可以研究下（求分享研究結果，因為我沒找到正則的設置位置）
使用 HTTPX 或者其他代理工具，原理和 fiddler 類似，不過可視化效果（體驗）要好很多，畢竟人家是專門做代理用的。
自己寫一段腳本代理，也就是本地開一個代理服務器，這里需要考慮端口的占用問題。其實我不推薦監(jiān)聽端口，一個比較不錯的方案是本地請求全部指向一個腳本文件，然后腳本轉發(fā)URL，如：
JavaScript

原始請求：http://barretlee.com/api/test...
在ajax請求的時候：

$.ajax({
  url: "http:///api.php?path=/api/text.json"
});

原始請求：http://barretlee.com/api/test.json
在ajax請求的時候：
$.ajax({
  url: "http:///api.php?path=/api/text.json"
});
php中處理就比較簡單啦：
JavaScript

if(!isset($_GET["page"])){
  echo 0;
  exit();
}
echo file_get_contents($_GET["path"]);

if(!isset($_GET["page"])){
  echo 0;
  exit();
}
echo file_get_contents($_GET["path"]);

Ctrl+S,保存把線上的接口數(shù)據(jù)到本地的api文件夾吧-_-||
三、小結

本文只是對前后端協(xié)作存在的問題和現(xiàn)有的幾種常見模式做了簡要的列舉，JSON Schema 具體如何去運用，還有接口的維護問題、接口信息的獲取問題沒有具體闡述，這個后續(xù)有時間會整理下我對他的理解。