憑API搭橋鋪路　企業應用直達雲端

API是企業直達雲端應用殿堂的天梯

前言：
當企業決定導入雲端服務，此後不論是應用程式開發者、用戶端應用程式開發者、部署者、管理者，乃至於雲端供應者，皆必須與此雲端接軌，其間賴以互通無虞的橋樑，即是應用程式介面(Application Programming Interface；API)，一旦有了API的輔助，上述各類型開發者都可化繁為簡，大幅省卻開發的負擔、時間與成本。

本文：
從美國國家標準與技術研究院(NIST)釋出「雲端運算工作定義」後，原本大家對於雲端運算之紛歧認知，開始定於一尊，確定雲端運算擁有SaaS、PaaS與IaaS等三種服務模式，也擁有公有雲、私有雲、混合雲與社群雲等四種部署模型，再加上「高度彈性」、「運算服務」、「隨需應變自助服務」、「網路使用無所不在」及「資源彙整」等五種基本特性。

隨著NIST標準定義的出爐，佐以相關解決方案、應用案例接續現身，至此雲端運算的輪廓漸趨清晰，有助於化解眾家企業的諸多疑慮，願意敞開心胸、投入雲端應用的用戶，已見大幅增加。

然儘管企業高層主管，對於雲端運算興緻勃勃，但其麾下必須奉命行事的開發人員，或許基於對雲端內涵之不夠瞭解，難免眉頭深鎖，視為畏途，因為雲端程式既然得執行在大量經虛擬化的分散式運算架構，那麼其所對應的設計、開發、測試與驗證準則，必然迥異於自己過去的所見所聞，如此一來，先前相對單純的工作內容，肯定會變得複雜許多，此時面對茫然不知的前路，還真的不知該如何做，才能走得又快又穩。

事實上，這些滿懷憂慮的開發者，之所以有所遲疑，也不是沒有幾分道理，並非全然是庸人自擾，但他們也許輕忽了API的妙用，也就是當你決定採用哪一家雲端服務，便可以藉由該供應商所提供的免費或要價不高之API，輕鬆搞定諸如程式碼回應、簽章運算…等大大小小瑣事，甚至連網路內部的資料格式與結構，也都有類似工具箱的機制代為處理，絕無開發者原本認知之勞心勞力；由此可見，API對於想要上雲的企業，真的就像是跨越鴻溝的橋樑。

欲與雲端互動，少不了API
API是什麼呢？簡言之，它是一種協議，可以明明白白地告訴開發者，需要如何撰寫程式碼，才能與其所對應的特定系統互動；究竟API告訴了開發者哪些事？除了系統運作所支援的語法外，還會針對每一項作業，闡明應當傳送哪些訊息給系統，而系統收到後，會回覆怎麼樣的訊息，並事先提醒未來可能出現的潛在錯誤，除此之外，API也涵蓋了譬如HTTP等通訊協定，或者譬如XML SCHEMA等資料格式。

至於定義API所應採用的程式語言，範圍其實很廣，比方說，未必具有機器可讀語言的REST法，即便如此，仍可被用以定義API，其餘例如Web服務描述語言(Web Services Description Language；WSDL)、介面定義語言(Interface Definition Language；IDL)，當然也很適合。

API在理解資料或作業的意涵時，需要根據參數予以識別，而參數通常表徵於兩組整數，得先由開發者自行定義這兩個整數，再由機器據此判讀參數，最終回饋成為資料及作業的語意。

根據Open Cloud Manifesto.org提供的文件，建立雲端應用服務的API，基本上可區分為四個層級或五種型態。有關四個層級，層級由淺而深，依序是網路、特定語言工具箱、特定服務工具箱及非特定服務工具，層級之不同，意謂開發所需關注的任務或資料屬性，皆有所區別；舉例來說，若採用層次最低的「網路」級API，開發者可直接撰寫網路格式的請求，且不論該服務植基於REST或SOAP都可，但以REST而論，開發者藉由HTTP標頭資訊、請求內容之建立，接著開啟連結服務的HTTP，而服務供應端接收訊息後，即會回覆資料並附帶HTTP回應碼，整段歷程一氣呵成，顯見在網路層級撰寫與REST服務相關之程式碼，效率確實很高。

反觀SOAP服務，開發人員則需建立SOAP信封、附加SOAP標頭，然後把資料內容置入這個主體，而服務供應端回覆時，係以SOAP信封裝載請求結果，看來與REST服務頗為神似，但內涵並不相同，因為SOAP服務涉及XML內容的解析，情況相對複雜，比較適合藉由更高層次來的執行。

一旦進入特定語言工具箱層次，開發者即便仍須按照REST或SOAP服務的需求，專注處理網路裡頭的資料格式與結構，但若論及處理回應程式碼，或者是計算驗證簽章等事項，都不再需要親力親為，工具箱可自動代為處理。

可以想見，層次更高一級的特定服務工具箱，API所能做到的事情，肯定愈來愈多；在此前提下，開發者僅需要關注於企業組織的資料及流程，可無須理會網路協定，應用開發效能自然更大。

最高層級的API－非特定服務工具箱，情況大致與前一級的特定服務工具箱相若，但兩者不同之處在於，非特定服務工具箱所意謂的是眾多雲端供應商的共同介面，而不是僅適用於特定場域，因此對於開發者更加省事，由此撰寫的應用程式，現今可套用於A供應商，未來還能移轉至B、C、D…等不同供應商，原應用程式可能完全無須改寫，或僅需些許更動即可。

開發角色有別，適用不同API
另外談到Open Cloud Manifesto.org所定義的五種類別API，分別是一般程式設計、部署、雲端服務、映像檔暨基礎架構管理、內部介面。先說內部介面，意指雲端基礎架構不同區之間的內部程式介面，舉例來說，若企業想從A供應商轉換跑道到B供應商，就需要採用此類API。

在映像檔暨基礎架構管理部分，則著重虛擬機器映像檔及基礎架構之管理，舉凡有關虛擬機器映像檔的API支援上傳、啟動部署、停止部署、重啟部署、刪除映像檔等功能，以及諸如網路、防火牆、運算節點、負載平衡等基礎架構管理細項，都落在此範圍內。

至於雲端服務，意指與雲端服務應配合的程式介面，此類API可對應於常見的雲端資料庫、雲端儲存服務或雲端訊息佇列等等不同服務，型態琳瑯滿目。

部署方面，顧名思義，即是企業將其應用程式部署在雲端的介面，內含譬如EAR(Enterprise Archive)、JAR(Java Archive)或WAR(Web Archive)，或.NET元件等傳統慣用之封裝技術，此外也涵蓋了雲端運算的特殊封裝機制。

有關一般程式設計，指的就是類似Java、C#或PHP等API，過去在非雲端環境，就經常出現這些API，如今進入雲端世代，其實前後並無太大差異，等於是五類API當中最為中性者。

一開始曾提到，舉凡應用程式開發者、用戶端應用程式開發者、部署者、管理者或雲端供應者等不同型態的開發者，都需要因應與雲端系統的互通，採用必要的API，各個角色與上述五大類API的對應關係如何？應用程式開發者部分，會使用到一般程式設計、或雲端服務等API；而負責撰寫用戶端應用程式的開發者，則適用於雲端服務API。

肩負包裝、部署與維護雲端應用之任務的部署者，抑或管理者，兩類角色定位需求較為近似，可能都需要因應雲端應用的生命週期循環，在不同階段採用到不同API，不管是部署型API、雲端服務型API或是映像檔暨基礎架構管理型API，都將派上用場。最後談到的雲端供應者，則經常運用其雲端供應項目下的基礎架構，因此對於內部介面型API，具有頗高的使用需求。