業界正在逐漸承認RESTful API優于面向服務架構。但是這對于架構師和開發人員而言到底意味著什么？Tom Nolle分享了他的想法。
在模塊化應用世界里，最為持久的爭論莫過于面向服務架構和表述性狀態轉移之爭了。本文探討這樣的爭論帶來了什么及其背后的原因。
SOA已經被定性為連接組件和工作流的嚴格的且重量級的方案，REST則贏得了更多的贊譽。兩者的特征都是簡化，但是要學習RESTful API設計，架構師和開發人員必須理解SOA和REST之間的差異，學習REST和云以及微服務一起的演進，并且了解如何構建穩定且合規的RESTful工作流。
SOA廣義上指基于連接的組件化服務的應用設計，基于這個定義，REST實際上是SOA的一種實現。實際API之爭是在簡單對象訪問協議（SOAP）及實現其Web服務標準和REST之間。這兩者有著本質的不同：SOAP從用于擴展網絡連接之上的模塊化編程的遠地過程調用演進而來，而REST從互聯網組件的“資源”角度而來。
有狀態 vs. 無狀態使用SOAP，網絡連接的組件是模塊，也就是說他們可以被看成帶有功能調用和參數的“過程”或者“類”。SOAP的目標是使得過程能夠在遠程工作，包括讓開發人員找到過程，并且將其正確綁定到執行上。在REST的世界里，組件代表請求訪問的資源——一個內部實現細節不透明的真正黑盒子。SOAP里不會假定遠程組件是無狀態的。本地過程以及REST則會假定調用是無狀態的；在執行之間RESTful服務不會駐留任何東西。
云計算和微服務幾乎已經使得RESTful API成為了既定業界標準，因此對于開發人員和架構師而言需要重點理解REST。
正是REST的無狀態特征使其在云應用里作用非凡。當錯誤發生時，無狀態組件可以隨意重新部署，也可以在負載改變時隨意伸縮。因為任意請求都可以發送到組件的任意實例上；不會有任何東西保存在另一個實例里，而需要下一次事務“記憶”住的。SOAP開發也可以這么實現，但并不是必須的。
基于這個原因，Web場景下更喜歡使用REST，不過在云服務里RESTful模型也很有用，因為通過API綁定到某個服務一般而言就是控制URL解析的方式。如果一個應用通過URL“知道”某個組件或者微服務，那么如果服務最初的實例出現故障，改變URL相關聯的IP地址就會讓請求路由到新的實例里。不需要其他額外的目錄管理。如果URL指向某個負載均衡器，那么使用簡單的算法就可以分發工作，因為沒有哪個請求特別需要某個“記憶”了狀態的特定實例來處理。
云和微服務云計算和微服務幾乎已經使得RESTful API成為了既定業界標準，因此對于開發人員和架構師而言需要重點理解REST。這意味著在應用里需要解決狀態控制的一致性，管理安全性，從而解耦合組件并且創建高效的服務目錄。
REST里有兩種管理狀態的方式——在RESTful調用里將狀態傳遞給服務，或者由服務的任意實例都可以訪問的后臺數據庫來維護狀態。如果想要RESTful應用像基于SOAP的應用一樣合規，那么就需要采取一致的方案。除非訪問后臺狀態數據庫的方案不現實，否則都應該考慮優先選擇后臺狀態管理。客戶端狀態控制在客戶端實例故障時會導致問題。
保證安全性
REST的安全問題很可怕，但是大多數情況下，這些安全問題的假設都是應用組件放置在開放的互聯網或者VPN里。簡單確定組件部署處的私有的RFC1918地址空間，可以大幅提高REST安全性。當組件間大規模集成對于應用而言必不可少時，這樣的方案就不適用了，那么就有必要使用安全連接，比如https。身份令牌也可以作為RESTful API數據包的一部分。
有很多REST目錄服務，ProgrammableWeb可能是其中最知名的服務，但是它們都關注于公開暴露的API。Internet社區內部關于私有RESTful API是否自相矛盾這個問題上存在爭議，但是從實用的角度，大多數公司都需要使用私有API目錄，從而讓開發人員可以訪問其RESTful API。否則，肯定會影響到企業數據和合規需求。
如果你在考察RESTful API目錄工具，首先需要關注那些為微服務而設計的工具，因為這是云API領域的整體趨勢。核心需求是支持三層API——私有內部或者甚至部門的API，“合作伙伴”或者社區API以及公開API。不過要記住，如果可以在網絡地址空間里訪問Web服務或者微服務，它就有可能被hack。即使API目錄有安全保障，也同時需要考慮恰當的地址控制或者工作流加密。
REST和微服務使得組件整合更為容易，并且提供了云和虛擬化應用大規模擴展和彈性的可能性。通過解耦合SOAP引入的組件綁定規則來實現，那么應用規劃師和開發人員可以通過其他方式實現安全和合規支持。REST和微服務在業界快速得到大量支持，因此需要在你的應用里準備好使用它們。
京公網安備 11010502049343號