先後端分離&接口API設計學習報告

接口API設計學習報告

15331023 陳康怡

什麼是API？

API即Application Programming Interface。API是一種通道，負責一個程序與另外一個程序的溝通。而對於web端開發而言，API能夠理解爲先後端協商好的交互規範。前端根據API規範發送請求，後端根據API規範響應請求。經過API能夠實現先後端分離。一個好的API可讓先後端的開發人員各司其職，專一於深耕本身的領域。

爲何先後端要分離？

傳統的MVC模型

傳統的MVC模型是很是好的協做模式，Controller、Model、View層分離，先後端分工比較清晰，但仍不足夠。

傳統MVC模型的典型問題：

1. 前端開發重度依賴開發環境，開發效率低。這種架構下，先後端協做有兩種模式：一種是前端寫demo，寫好後，讓後端去套模板。這種模式的好處是前端能夠基於本地開發demo，效率高。不足之處在於前端所作的demo須要後端使用模板再改寫一遍（如HTML改成JSP），容易出錯，溝通成本高。 另外一種協做模式是前端負責瀏覽器端的全部開發和服務器端的 View 層模板開發。 好處是 UI 相關的代碼都是前端去寫就好，後端不用太關注，不足就是前端開發重度綁定後端環境，環境成爲影響前端開發效率的重要因素。

2. 先後端職責仍舊糾纏不清。頁面路由等功能本應該是前端最關注的功能，但倒是由後端實現。Controller層與Model層每每也會糾纏不清。

3. 對前端發揮的侷限。後端性能優化受後端框架限制，難以使用Comet、Bigpipe等技術方案來優化性能。

分離的目的：
1. 關注點分離
2. 職責分離
3. 對的人作對的事
4. 更好的共建模式
5. 快速的反應變化

先後怎麼分離？

第一階段：基於Ajax的SPA：

CDN（內容分發網絡）發送網頁內容，經過基於JavaScript的AJAX實現與後端的交互。缺點是瀏覽器端會十分複雜，尤爲是JavaScript部分的代碼。

第二階段：瀏覽器端的分層架構：
先後端約定交互規範，前端在瀏覽器端完成業務邏輯。前端須要數據時，根據API向後端請求，後端根據API發回響應（通常爲JSON格式）。前端獲得數據後使用模板引擎渲染顯示。

先後端分離的難點：

1. 先後端接口的約定。若是後端接口設計存在缺陷，或業務模型不夠穩定，那麼前端開發會很痛苦。這一塊在業界有 API Blueprint 等方案來約定和沉澱接口，==在阿里，很多團隊也有相似嘗試，經過接口規則、接口平臺等方式來作。有了和後端一塊兒沉澱的接口規則，還能夠用來模擬數據，使得先後端能夠在約定接口後實現高效並行開發。== 相信這一塊會越作越好。

2. 前端開發的複雜度控制SPA 應用大多以功能交互型爲主，JavaScript 代碼過十萬行很正常。大量 JS 代碼的組織，與 View 層的綁定等，都不是容易的事情。

後端	前端
提供數據	接收數據，返回數據
處理業務邏輯	處理渲染邏輯
Server-side MVC架構	Client-side MV*架構
代碼跑在服務器上	代碼跑在瀏覽器上

API設計原則

1. 接口返回數據即顯示：前端僅作渲染邏輯處理；
2. 渲染邏輯禁止跨多個接口調用；
3. 前端關注交互、渲染邏輯，儘可能避免業務邏輯處理的出現；
4. 請求響應傳輸數據格式：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

參考連接：

1. https://www.jianshu.com/p/c81008b68350
2. http://www.ruanyifeng.com/blog/2014/05/restful_api.html