轉:咱們是否應該把後端構建爲API

原文來自於:http://www.infoq.com/cn/news/2015/07/api-or-not

不久前，在StackExchange網站上，一位名爲SLC的用戶提起他正在設計一個ASP.NET網站，他對因而否要將後端設計爲API有些舉旗不定，但願可以獲得一些建議。一石激起千層浪，這個帖子很快獲得了大量的關注與回覆。如今讓咱們來了解一下SLC所面臨的具體狀況與問題。

SLC設計的網站是一個典型的ASP.NET MVC應用，他在開發時使用的都是一些經典的MVC模式，即控制器、視圖與模型的結合，在控制器的方法中調用某個Manager對象以獲取數據並建立視圖模型。原本沒什麼問題，但他的某位同事對此表示異議，認爲這種代碼的耦合性太強，如若要建立一個桌面版本的應用，這些代碼就沒法重用了。他所推崇的最佳實踐是建立一套API，在此基礎上開發網站、桌面應用或者移動應用就都不成問題了。

SLC對此見解持保留意見，他列舉了幾條他認爲這種作法不合適的緣由：

• 將後端設計爲API有過分抽象之嫌，巨大的靈活性同時也意味着巨大的複雜度；
• MVC中的一些內置特性將變得無用武之地，例如與角色和認證相關的功能都要從新設計；
• 爲了保證API調用的安全性，必須設計某種令牌系統，在每次API調用中都要附加相應的令牌；
• 整個程序中的每一個功能都必須編寫一個對應的API調用；
• 在API中沒法利用接口或抽象類等工具，像WCF這樣的框架對於接口的支持很是有限；
• 在桌面或移動應用中一般要避免細粒度的API調用，所以不得不爲支持這些系統建立一些批量方法或粗粒度的方法；
• 這違反了YAGNI原則，除非你已肯定要同時支持多種具有相同功能的應用，不然只是無謂地增長開發工做量；
• 因爲沒法實現端到端的單步執行，調試變得很是困難。

支持者

用戶gbjbaanb堅定支持使用API設計後端的方式，他認爲這種方法不只使得代碼能夠重用，而且可以帶來更高的安全性與更好的設計。而一體性的實現會形成架構的僵化，難以擴展、替換及改進。他還以時下最流行的微服務爲例，在這種設計中的後端實現爲多個小型的服務，它們各自提供一套API以供客戶端進行調用。他同時也指出了SLC對於API的概念存在誤解之處，API並不是一種遠程類庫，而更像是一種提供數據的服務。網站能夠經過API獲取數據，並在本地對數據進行某些操做。

gbjbaanb也對SLC所列舉的部分觀點進行了點評：

• MVC自己就是遵循隔離服務概念的一種設計，只是ASP.NET MVC框架將這些設計元素組織在一塊兒而已。所以使用API並不表明放棄了MVC思想，只是缺乏了這一框架中的一些輔助方法。若是過於依賴這些輔助方法，就等於將本身綁定在這一框架上，這種狀況下能夠編寫本身的輔助方法，或尋找一些第三方類庫。
• 調試也同樣簡單。首先因爲API是一個獨立的層，所以徹底能夠對API進行隔離測試，這種狀況下甚至不須要進行調試。若是確實須要進行端到端的調試，那麼也能夠打開多個Visual Studio，同時附加到多個進程上進行調試。
• 爲了保證安全性而進行額外的設計，這實際上是一件好事。若是將全部安全方面的代碼都實如今網站中，一旦黑客攻破了Web服務器，就等於得到了全部訪問權，包括數據庫。而若是設置了一個額外的API層，那麼安全性就能夠大大提升。

gbjbaanb最後爲SLC提了一些設計方面的建議，從分層架構的角度看，網站是一種展現層，而API則是應用層。對於業務邏輯的設計能夠看狀況選擇以數據爲中心，或是以領域爲中心的方式，固然後者顯得更「純淨」一些。

反對者

而反對API的聲音也很多。fotijr表示雖然微服務是當下的熱點，但這不表明這種作法老是值得的。鬆耦合當然是好事，但若是所以讓整個開發週期變得過於痛苦，那就得不償失了。他同時建議將模型放在一個獨立的數據訪問項目中，以便MVC或桌面應用能夠直接重用。JacquesB也不支持設計爲API的作法，他認爲單純地建立API並不可以保證鬆耦合性，若是設計不當，反而會出現跨服務器邊界的緊耦合性。

一點拙見

接下來筆者將簡單地表達一下對此問題的我的意見。首先是對API的理解，原做者彷佛將API簡單地理解爲一種獨立進程的分佈式的API，例如Web API、Remoting或RPC調用。其實從廣義上來講，只要是經過代碼調用後臺的業務邏輯與數據，均可以理解爲一種API。所以問題不在於要不要設計API，而是如何設計這套API。

接下來看一下原做者的設計方式，他所使用的方法是在控制器方法內調用某個Manager對象的方法以訪問數據，那麼大概能夠推測出他的業務邏輯是以一種以數據爲中心的設計思想，所使用的模式極可能是事務腳本（Transaction Script）。這種方式的優勢在於簡單易懂，但這樣設計出的模型極可能是一種貧血模型，即業務邏輯大量散落在對應於用例的應用層的方法中，隨着時間的推移，其難以維護的缺點將會逐漸暴露出來。

比較好的方式是遵循關注分離的設計原則，將業務邏輯與對應用例的應用邏輯進行隔離，將業務邏輯放在一個具備高度內聚性的領域層中，而展現層（即網站、桌面或移動應用）經過應用層間接地調用相應的業務邏輯。從這一角度來講，SLC所需的API正是應用層所暴露的方法與對象（例如數據傳輸對象），而他本人在以後的回覆中也表示了對這一點的理解。至因而否要將應用層的API設計爲分佈式，這已經不是主要的問題所在了。

關於經過API實現重用性，讓同一套邏輯可以適用於不一樣的展現層，這一點筆者並不認同。誠然，在分層架構（或其它相似的架構)中，理論上是有可能重用相同的應用邏輯的。但在實際應用中，因爲客戶端的不一樣特性，每每會對應用邏輯進行某種程度的調整，以實現最優化的用戶體驗。在網站中使用的Composite UI風格，在移動端可能會被設計爲Task Based UI，而UX以及用例的區別將直接致使應用層API的變化。若是要堅持重用應用邏輯，勢必要對UX做出某種程度的妥協，在作出重用這一決定時，軟件組織必須對它的影響有深入的理解。

其實在筆者看來，分層的最大好處在於保持了設計與代碼的整潔性，有利於長期的設計演變與代碼維護，而且可以促進單元測試，同時能夠對不一樣的層進行並行開發、測試與部署。相信這也是SLC的同事的本意所在。