API的宣告性力量
今天API在行業中發揮著重要作用，為硬體和軟體開放了管理和程式設計功能。API使IT運營部門能夠輕鬆地將新舊產品整合到現有的自動化編排和服務流程中，使事情更易於管理，並縮短產品上市時間和策略。為什麼現在投入API？這些曾經“僅限開發人員”的介面進入IT運營世界的原因是什麼？
宣告性轉變勢在必行
從歷史上看，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確定最佳的實現方式