API的宣告性力量

宣告性轉變勢在必行
從歷史上看，IT運營採用了更為迫切的管理型別方法，將特定指令傳送到基礎架構並執行。如果不正確，則會傳送更多指令和命令以執行其他操作。雖然這種方法多年來運作良好，但它有其缺陷 - 首先是它作為人類使用來指揮我們的基礎設施。插入人的元素帶來了許多風險 - 人類犯錯誤，人類需要時間。
在“軟體定義”世界中，正在發生重大轉變 - 從傳統的命令式方法轉變為宣告式方法。我們現在只需定義一個理想的最終狀態，告訴基礎設施最終如何到達我們的目的，而不是一個一個地向我們的基礎設施傳送命令。
舉個例子，想象一下你邀請某人到你家。為了讓這個人到達你的家，你必須給出確切的指示 - “從主街直行，然後在...我的房子是左邊第九個房子，經過那個十字路口。“這是思維的必要模式。或者使用宣告模型，我可以說“我的地址是XXX街XXX號; 將其輸入GPS應用程式 - 它將使用最佳路線導航您。“
也就是說，為了協調基礎設施，軟體需要一個共同點來提供通訊渠道。RESTFul API帶來了標準化且易於使用的架構，IT運營部門可以利用該架構，協調資料中心所有角角落落的流程。RESTFul API使IT操作在實現宣告性的，期望的最終狀態方法方面更加接近。

軟體已經改變
不只是IT運營發生了變化 - 部署的軟體和解決方案也正在發生重大轉變。比較10年前的資料中心與今天的資料中心存在顯著差異。曾經長期依賴的單片式基礎設施已經讓位於更加模組化的方法。雲和微服務現在正在承擔我們工作負載的衝擊，提供小型，可重複使用的程式碼塊，這些程式碼組合在一起以提供大型複雜的應用程式。它們不是在應用程式級別管理工作負載，而是現在可以分解為小的，短暫的部分。當服務不可用時，另一個服務就會取而代之 - 當需要擴充套件時，分散式檔案系統允許多個節點協調工作，為整個應用程式提供更多資源。
RESTful API提供標準化的無狀態架構，允許我們整合和自動化這些不同的獨立軟體解決方案，將所有應用程式歸結為一個共同點。
從歷史上看，IT運營部門可以部署一個單獨的軟體套件，該套件通常帶有管理該應用程式所需的一切 - 如今，大型分散式資料中心已不再適用。以VM生命週期為例 - 僅僅基於黃金模板部署VM是不夠的。還有許多其他流程和任務需要考慮在內。VM是否需要包含在您的資料保護解決方案中？我們是否需要對VM中執行的服務和應用程式進行任何標準監控？是否需要將VM新增到任何變更管理或資產跟蹤應用程式中？為了部署真正的宣告性VM供應過程，需要考慮與VM相關的所有應用程式和過程。
RESTful API提供標準化的無狀態架構，允許我們整合和自動化這些不同的獨立軟體解決方案，將所有應用程式歸結為一個共同點。不依賴於任何特定的底層技術意味著IT運營可以輕鬆地將新服務整合到現有的自動化工具集中。API與抽象的管理和操作層相結合，提供了一種提供高度自動化的橫向擴充套件解決方案的方法。

所以REST就在這裡
RESTful API提供IT運營一直渴望的無狀態通用架構。不再需要專有的CLI - 只需將編排和自動化整合到現有的工具集中。REST獨立於平臺，無論底層語言如何都可以執行。僅從2000年初開始，我們已經看到利用RESTful API的連線裝置的數量急劇增加，沒有任何放緩的跡象。RESTful API將在資料中心管理的未來發揮重要作用 - 因此，要好好了解當前基礎架構中的應用程式，硬體和軟體，並清除那些不提供RESTful API的人。

定義所需的最終狀態，讓軟體和RESTful API確定最佳的實現方式