在多年以前,API(Application Programming Interface)像是一個很特定、很專門的軟體領域,只有很少數的人才會需要設計、開發 API,例如作業系統的開發者。我們絕大多數的人,都是 API 的使用者,就像 Windows 的應用程式開發者,幾乎都會成為 Windows 作業系統 API 的使用者一樣。

不過,隨著軟體重複使用程式碼的觀念愈來愈興盛、層次畫分愈來愈細,在作業系統的 API 之上,有愈來愈多應用層級的 API設計出來。針對不同的應用領域,從低階到高階,讓位處在最高層的應用程式,愈來愈容易在底層的 API 的支持之下,輕鬆開發出應用程式。

API開發的目的是什麼?實際使用上,有那些方式?

最早我們對 API 的概念很簡單,API 大抵上是專門以服務第三方的開發團隊做為目的。就像很多年前,微軟內部有個開發共用程式碼的團隊,他們開發出來的產物,同時要供Microsoft Word 及 Microsoft Excel 使用一樣。這個團隊專門就是在開發 API,提供其他團隊,像是 Word 或 Excel 團隊來使用。

事實上,現在我們所運用的許多 API,也都是專門為了第三方的開發團隊而設計、提供的。

像是我們會用 Facebook 提供的 Graph API ,來存取 Facebook 為了其應用程式開發者而提供的各種服務,或是利用 Google開放的 YouTube API ,來存取 YouTube 上的資料。

不過,另一方面,即使是開發同一個產品或服務的團隊,也可能在開發產品或服務的過程中,設計並開發出一些 API,其原始的目的與考量,不見得是為了供第三方使用,而是為了自身在開發產品或服務使用。

這的確是個有趣的轉變,從什麼時候人們開始這麼做?這麼做能帶來什麼好處呢?

開發應用的同時,不單是實作相關功能,也涵蓋到API

最近我們有一個線上影音串流的服務推出,允許使用者從一些不同的終端上收看線上影音,包括了手機、平板電腦、機上盒,以及電視,作業系統包括 Android以及 iOS。當然,在不同平臺上的應用程式都是不同的實作。

可是,即使是不同的實作,它們還是共用置放在雲端上的服務。也因此,我們為雲端上的這組服務設計了對應的 API,並且在 Android 及 iOS 平臺上,都實作了這組API 的對應實作,這使得 Android 及 iOS 上的應用程式,都可以同樣的概念及模式,來存取雲端上的服務。

事實上,這並不是我們第一次這麼做了,從很多年前,當我們設計、開發相關的服務時,除了應用程式本身的開發之外,也同時將服務端的部份,以 API 的形式來設計及實作。

所以,我們可以說,是在開發應用程式的過程中,同時也開發出這個應用程式所需的 API,而在之後,在其他平臺的應用程式,也因此順理成章,共用了相同的 API 介面。

採用API形式來設計各種應用服務的好處多

即使,我們一開始沒有打算將這組服務提供給第三方使用,而只打算供給內部,但仍然以 API 的形式及規格,來設計這服務對應的 API。

而且,其實,你也可以看到,有很多的團隊也都這麼做。這已經形成一種開發應用程式的方法,也就是在開發時,將應用程式本身再拆解成兩個部份。

一個是核心的部份,一個是外圍的部份,二者獨立設計、獨立開發,但外圍的部份,相依於核心的介面。

核心的部份,可以說是外圍部份的API,它是具備一般化、通用的部份,而外圍的部份,則基於核心部份的API ,實作應用程式中特化的部份。

將應用程式如此畫分,可以得到一個顯而易見的優點,是日後一旦要「換殼」,也就是要更換外圍部份的時候,核心的部份完全不受影響,也毋需改變,只需要開發出新的「殼」即可。

例如,原先只是開發在 Android 平臺上的應用程式,但即使之後增加了開發 iOS 平臺應用程式的需求,也只需要增加 iOS 部份的實作而已。

也就是說,在這種方式底下,我們在一開始就把可能會被重複運用的部份先抽離出來,並且將它們以 API 的形式來呈現,這使得日後我們要開發新的應用程式時,直接可以沿用這組 API。

所以,程式碼的重複使用,將會是這種方式顯而易見的好處。

當 MVC(Model View Controller)的設計模式,或是SOA(Service Oriented Architecture)之類的設計方法,開始廣泛使用之後,許多人將對 Model 或是服務的存取,包裝成為 API 的形式。

另一方面,由於同一個應用經常被要求提供跨平臺的實作,例如,行動應用程式時常被要求要同時提供 Android 及 iOS 兩種平臺的應用程式實作,但其實骨子裡是相同的服務。現在流行的方式,是將真正的核心程式置於雲端之上,並且,將核心的部份以 RESTful  API的形式提供服務。

而 Android 或 iOS 的應用程式,基本上的責任,也只有接收來自使用者或裝置的輸入(像是觸控、手勢、GPS 位置、麥克風、相機、……等等),以及顯示使用者介面,並與使用者互動。

絕大多數的核心程式,都包裝成為運行在雲端上的服務,而且可以被諸多不同平臺上的實作所共用。

思考應用當中不變、共通的部分,提升當中的再用性

這種在開發自身應用程式時,即將應用程式畫分為 API 及應用實作兩部份的設計方法,還有一個好處,也就是它有助於設計者更認真思考:自己正要開發的應用中,究竟那些部份是可以維持較長時間不變,而保有其一般性,以及那些部份是容易隨著實作而變動的部份。

當你在設計一組 API 時,你不僅會考慮到在自己正在開發的這個應用中的需求,同時也會考慮到,倘若有第三方的開發者,也想要開發一個和這個應用核心精神相同,但展現實作不同的應用程式時,這組 API 是否足以滿足他們的需求?

當你用 API 的規格來看待、想像,可能有一天你會釋出這組 API 供第三方開發者使用時,基於這樣的思考方式,將能幫助你寫出通用性更高的程式碼,進而帶來了更高的可重複使用能力。

那些和平臺相依、隨著實作會有所變動的,都會被你從核心的部份抽離,而核心的部份,只會保留較純粹的特質。

當你在開發應用程式時,試著將應用畫分成為 API 以及應用實作兩個部份時,能夠幫助你更明確的思考那些是核心,因為你在依循 API 的設計觀念時,會將它們包裝成為 API。

但是,有些人不會隨時保持著這樣的思考方式,使得他們時常將二者混雜在一塊,也就不容易寫出足夠通用、能持續被重複運用的程式碼了。

即使我們不打算開放內部使用的 API 供第三方使用,但是,在開發應用時,如果能夠總是先想到有那些可以成為 API,並且用 API 的規格去設計實作,對自身的應用之開發,如此一來,還是可以帶來不少好處的。

專欄作者

熱門新聞

Advertisement