API優先架構或者胖瘦伺服器之爭

自2007年HTTP://www.aliyun.com/zixun/aggregation/5541.html">Apple發佈了iPhone，網路應用及網站在小螢幕上的呈現機會顯著的增高， 從而各大網站及機構不得不對其應用進行適當的改變。 然而考慮到資料體積、應用程式擴充性、新特性的發佈及維護等問題，應用程式的架構也不得不按需進行改變，比如Twitter的面向服務。 近日leaseweblabs上發表了一篇文章，詳述了API優先架構。


　　以下為譯文：


　　在API優先架構中，API使用者會被視為應用程式的主要使用者。 這意味著API不會再作為MVC中View的替代，它將擁有最高的優先權。 其中最主要的區別就是：在「API優先」中，架構會始終執行一個完整、回應式及文檔化的API。 而當目標指向移動（應用聯連接到API）、代理商（展示層會使用API）及高整合、解耦的多產品環境中，這一點尤為重要。


　　MVC


　　MVC架構已經流行了很長一段時間，在2004年RoR發佈後，MVC變得愈加炙手可熱。 在MVC情況下使用者和員工分別使用前端和後端兩個不同部分，可以大幅提高應用程式中元件的重用率。 合適的使用MVC策略，可以讓應用程式的很多部分都得以重用，其中包括DBAL/ORM、Business Logic、Presentation及AAA。 AAA（Authentication、Authorization、Accounting）允許員工類比使用者行為，使用相同的登錄介面及共用日誌設備。


　　移動中的視圖層


　　在2007年，Apple發佈了iPhone，從那起網路應用程式（及網站）在小螢幕上的展示率迅速升高。 同時MVC對小屏的相容一直非常優秀，需要做的只是在手機或平板上開一個視圖層的分支並做相關調整。 這種建立獨立視圖層的策略被稱為「mobile first」，也是最具成本效益及激進的修改途徑。 另一個替代方案是建立兩個視圖層：1個為行動裝置，另一個為桌面設備。 移動端的通常以「m.」 的子功能變數名稱開頭（比如m.csdn.net），非常簡單及直觀的一個途徑。


在MVC中加入API


　　「HTML5 vs 820.html">Native」應用開發之爭可謂是如火如荼，引用Danny Brown的話就是：


　　當公司在建立移動應用時會面臨一個重要的抉擇，Native或者是HTML5。 每個方案都有自己的優勢，然而錯誤的選擇必將付出高昂的代價。


　　選擇Native則需要建立一個完整、回應式及文檔化的API，然而選擇HTML5只需要重設計檢視層。 每種方案都有自己的優越性，只有相應的場景下才有勝負之分。 所謂存在即有道理，沒有哪種方案是永遠的失敗者：在MVC上建立API作為視圖。 下面就看一下，為什麼許多人都選擇了另一種。


　　首先，MVC途徑需要200ms的頁面載入時間。 在這個途徑下，伺服器做3樣事：資料庫抽象、業務邏輯及呈現，這也是其為什麼被稱為fat server的原因。 API並不會承擔呈現工作，只執行每個請求較小的業務邏輯，也因此被命名為thin server。 一個好的API會經過高度的優化，載入時間通常低於20ms。 這就意味著，在執行多重調用時（高達10），一個完整頁面的渲染時間不會超過300ms。


　　當下，如果你在使用MVC並且缺乏1個API，最容易做的事情就是添加一些View，用以輸出JSON，並稱之為「restful API」，唯一需要做的就是寫一些文檔並取悅于老闆。 實際上，在整個週期中，這個API完全不可用，因為其並不具備擴充性，同時還慢的可怕。


　　Twitter及API優先架構


　　在2010年，Twitter公佈了他們的「API first」策略。 鑒於其應用程式使用的是JavaScript，因此稱之為JavaScript架構，類似于移動應用的架構。 這允許他們完全重利用已有的API，這些開始時臨時使用的API，在以後開發週期中卻成為應用的基礎。 通過使用一個restful JSON API，他們的API專注于JavaScript應用程式的最佳整合。 但Twitter同樣使用了傳統頁面支撐其應用，他們曾發佈：


為了不通過JavaScript支援crawler及使用者，我們需要同時運行在伺服器及用戶端上的1個渲染系統。


　　使用傳統網頁交付方式，同時使用API優先策略，這裡簡單稱之為「Hybrid」。 下圖列舉了不同的途徑：


　　結論


　　優化重用可以降低成本，但是只有在強壯的架構策略下才能得以實現。 雖然重整代碼以增加架構上的依從（compliance）並不能直接給業務帶來價值，卻可以降低應用未來修改時的成本，然而這種程度的說服力顯然難以服眾。