在組件化應用程式世界中，爭論最久的似乎是在面向服務的體系結構和表示狀態轉移之間的爭論，
SOA已經成為組件連接和作業流的僵化和重量級方法，而REST越來越受歡迎，這兩種特性都很簡單，但是要開始使用RESTful API設計，架構師和開發人員必須了解SOA和REST之間的區別，跟蹤REST在云和微服務中的發展，并知道如何構建可靠且兼容的RESTful作業流，
SOA是基于鏈接和組件化服務的應用程式設計的廣義術語，從廣義上講，REST實際上是SOA的一個實作，API是簡單物件訪問協議（SOAP）和用于實作它和REST的Web服務標準之一，兩者之間的差異源自它們的根源：SOAP是從用于通過網路連接擴展模塊化編程的遠程程序呼叫技術演變而來的，而REST是從Internet的組件“資源”視圖演變而來的，
有狀態與無狀態
在SOAP中，網路組件是模塊，這意味著它們可以被看作是帶有函式呼叫和引數的“程序”或“類” ，SOAP的目標是使程序以遠程形式作業，包括讓開發人員找到程序正確地系結到程序并執行，使用REST，組件代表您請求訪問的資源，其實作細節是不透明的，SOAP不能假定遠程組件是無狀態的，對于本地程序也是如此，其中使用REST的前提是所有呼叫都是無狀態的；RESTful服務在執行之間不能保留任何內容，
正是這種無狀態的屬性使REST在云應用程式中變得有用，如果出現故障，可以自由地重新部署無狀態組件，并且可以進行縮放以適應負載變化，這是因為任何請求都可以定向到組件的任何實體，在另一個實體中保存的任何內容都不能以某種方式被下一個事務“記住”，
僅出于這個原因，REST是Web使用的首選，但是RESTful模型在云服務中也很有用，因為通過API系結到服務只是控制URL的解碼方式，如果應用程式通過URL“知道”某個組件或微服務，那么如果原始組件實體失敗，更改與該URL關聯的IP地址將使請求重定向到實體，不需要其他目錄管理，如果使URL指向負載均衡器，那么簡單的演算法就可以分發作業，因為任何請求都不能由“記住”狀態的實體來處理，
云和微服務
云計算和微服務幾憾訓使RESTful API設計成為未來的規劃，因此，對于開發人員和架構師而言，充分利用REST至關重要，這意味著在應用程式中一致地處理狀態控制，在組件耦合較松的情況下管理安全性，并創建有效的服務目錄，
有兩種方法可以管理REST中的狀態，在RESTful呼叫中將狀態傳遞給服務，或者讓服務的任何實體都可以訪問后端資料庫來維護狀態，如果您希望RESTful應用程式像基于SOAP的應用程式那樣兼容，那么采取一致的方法至關重要，除非訪問后端狀態資料庫是不切實際的，否則請考慮將后端狀態管理作為首選，如果客戶端實體失敗，客戶端狀態控制可能會導致問題，
保持安全
REST中的安全性問題可能是可怕的，但在大多數情況下，它們都與應用程式的組件在開放Internet或VPN上處理的假設有關，REST安全性中的一個主要步驟可以簡單地通過建立一個私有RFC1918地址空間來實作，組件部署在這個地址空間中，如果由于組件間的廣泛集成對應用程式至關重要而無法實作，那么使用https之類的安全連接就足夠了，Token也可以成為RESTful API資料包的一部分，
REST和微服務可輕松實作組件集成，并在云和虛擬化應用程式中提供了更大的可伸縮性和恢復能力，盡管他們這樣做的部分原因是放寬了SOAP組件系結的嚴格規則，但應用程式規劃和開發人員可以通過其他方式增強安全性和合規性支持，無論如何，REST和微服務似乎正在迅速獲得支持，因此明智的做法是準備在自己的應用程式中使用它們，
翻譯：Eolinker——企業級API介面管理平臺
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/261282.html
標籤：其他
上一篇：API工具的三個基本功能