叢集前後端分離（api介面）
介面API設計學習報告
轉自：TP
15331023 陳康怡
什麼是API？
API即Application Programming Interface。API是一種通道，負責一個程式與另一個程式的溝通。而對於web端開發而言，API可以理解為前後端協商好的互動規範。前端根據API規範傳送請求，後端根據API規範響應請求。通過API可以實現前後端分離。一個好的API可以讓前後端的開發人員各司其職，專注於深耕自己的領域。
為什麼前後端要分離？
傳統的MVC模型
傳統的MVC模型是非常好的協作模式，Controller、Model、View層分離，前後端分工比較清晰，但仍不足夠。
傳統MVC模型的典型問題：
前端開發重度依賴開發環境，開發效率低。這種架構下，前後端協作有兩種模式：一種是前端寫demo，寫好後，讓後端去套模板。這種模式的好處是前端可以基於本地開發demo，效率高。不足之處在於前端所做的demo需要後端使用模板再改寫一遍（如HTML改為JSP），容易出錯，溝通成本高。 另一種協作模式是前端負責瀏覽器端的所有開發和伺服器端的 View 層模板開發。 好處是 UI 相關的程式碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度繫結後端環境，環境成為影響前端開發效率的重要因素。
前後端職責仍舊糾纏不清。頁面路由等功能本應該是前端最關注的功能，但卻是由後端實現。Controller層與Model層往往也會糾纏不清。
對前端發揮的侷限。後端效能優化受後端框架限制，難以使用Comet、Bigpipe等技術方案來優化效能。
分離的目的：
- 關注點分離
- 職責分離
- 對的人做對的事
- 更好的共建模式
- 快速的反應變化
前後怎麼分離？
第一階段：基於Ajax的SPA：
CDN（內容分發網路）傳送網頁內容，通過基於JavaScript的AJAX實現與後端的互動。缺點是瀏覽器端會十分複雜，尤其是JavaScript部分的程式碼。
第二階段：瀏覽器端的分層架構：
前後端約定互動規範，前端在瀏覽器端完成業務邏輯。前端需要資料時，根據API向後端請求，後端根據API發回響應（一般為JSON格式）。前端得到資料後使用模板引擎渲染顯示。
前後端分離的難點：
前後端介面的約定。如果後端介面設計存在缺陷，或業務模型不夠穩定，那麼前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉澱介面，在阿里，不少團隊也有類似嘗試，通過介面規則、介面平臺等方式來做。有了和後端一起沉澱的介面規則，還可以用來模擬資料，使得前後端可以在約定介面後實現高效並行開發。 相信這一塊會越做越好。
前端開發的複雜度控制SPA 應用大多以功能互動型為主，JavaScript 程式碼過十萬行很正常。大量 JS 程式碼的組織，與 View 層的繫結等，都不是容易的事情。
後端 前端
提供資料 接收資料，返回資料
處理業務邏輯 處理渲染邏輯
Server-side MVC架構 Client-side MV*架構
程式碼跑在伺服器上 程式碼跑在瀏覽器上
API設計原則
介面返回資料即顯示：前端僅做渲染邏輯處理；
渲染邏輯禁止跨多個介面呼叫；
前端關注互動、渲染邏輯，儘量避免業務邏輯處理的出現；
請求響應傳輸資料格式：JSON，JSON資料儘量簡單輕量，避免多級JSON的出現；
RESTful介面規範
RESTful介面規範，是基於REST理念設計的介面規範，具體詳見：http://www.ruanyifeng.com/blog/2014/05/restful_api.html
REST本身並沒有創造新的技術、元件或服務，而隱藏在RESTful背後的理念就是使用Web的現有特徵和能力， 更好地使用現有Web標準中的一些準則和約束。
API文件編寫
API文件編寫需要包括：
簡要描述
請求URL
請求方式、引數
返回示例
返回引數說明
備註
這裡是一個示例：http://www.showdoc.cc/web/#/demo?page_id=9
參考連結：
https://www.jianshu.com/p/c81008b68350
http://www.ruanyifeng.com/blog/2014/05/restful_api.html