憑API搭橋鋪路 企業應用直達雲端 智慧應用 影音
Microchip
ST Microsite

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

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,具有頗高的使用需求。