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

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

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

一、開發(fā)流程

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

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

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

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

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

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

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

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

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

JavaScript

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

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

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

二、核心問題

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

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

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

接口文檔這個(gè)事情，使用 JSON Schema 可以自動化生產(chǎn)，所以只需編寫 JSON Schema 而不存在維護(hù)問題，在寫好的 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ù)獲取做了封裝，我們在測試的時(shí)候使用 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é)點(diǎn)去請求數(shù)據(jù)，但是 POST，只能呵呵了。

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

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

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

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

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

原始請求：http://barretlee.com/api/test.json
在ajax請求的時(shí)候：
$.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文件夾吧-_-||
三、小結(jié)

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