API設計和應用程式設計的不同？

所謂的API，就是應用程式介面（Application Programming Interface），讓開發者得以憑藉著這組介面，而更便利地開發應用程式。

記得最早開始接觸API 的概念，即在開發 MS-DOS 應用程式時，MS-DOS 作業系統透過系統中斷 INT 21H 來提供應用程式呼叫各種作業系統所提供的服務，像是建立目錄、刪除目錄、建立檔案、刪除檔案、……等等。這使得 MS-DOS 應用程式毋需自行開發檔案系統管理的種種機制，而可以立足在作業系統的基礎上，省去了許多的時間和力氣。MS-DOS 是以「系統呼叫（System Calls）」來做為其API 的名稱。

在之後接觸了 Unix應用系統開發，作業系統同樣也提供了一組 API，允許應用程式運用。

可以想見的，作業系統是應用程式的基礎設施，提供了眾多的服務，就以當今典型的作業系統來說，會有檔案管理、行程管理、使用者帳戶管理、……等等。針對應用程式所共通需要的部份，以 API 的形式來提供程式設計上便利的途徑，以便取用這些服務，明顯可以簡化應用程式的開發，更何況有些動作甚至只適合在作業系統層級的權限來進行。

除了作業系統的 API 之外，也有一些為了滿足應用程式在特定領域需要而設計出來的 API，這些特定領域可能像是繪圖、音效控制、報表產生、科學運算、……等等。

這種類型的 API，並非作業系統所提供，而是以程式庫、應用程式框架之類的形式存在，整理、萃取出特定領域中應用程式的共通需求而成，使得該領域中的不同應用程式，都可以透過API的實作品，來得到開發的諸多好處。我們在開放原始碼的世界裡，可以找到許多好用的 API，而且也可以對日常的開發提供助益。

有些時候，API 並不完全是第三方所設計的，我們也時常使用團隊內部、或是同一個公司中其他團隊所設計的 API。

這通常都是一些更細緻、更特定的需求，並不是第三方 API 所會考慮到的，以致於由內部的開發者自行設計。

同樣是軟體設計，了解開發API與應用程式之間的異同

我們大多都不是參與作業系統開發的設計者，但我們或許是第三方 API 或是內部 API 的設計者。做為 API 的設計者，和應用程式的開發者相較起來，雖然都是軟體設計、程式碼撰寫，但在很多層面上，都不盡相同。

API 的設計和實作有什麼不同的差異點呢？

首先，API 的使用者還是程式設計者，他們可能也是 API 的設計者，也有可能是應用程式設計者。但應用程式的使用者通常是人類使用者（當然有時候也會是其他的應用程式，二者透過一些方式溝通）。

因為這個差別，使得 API 若是做為一個產品，要提供的產出就不同。例如，API 的發行通常需要有 API 本身的說明文件，而且，最好有範例程式用以解釋如何運用 API 於應用程式的撰寫中。當然，如果有教學指引，一步一步帶著程式設計者學習使用 API ，那就更理想了。

正因為「使用者」對象不同了，所以 API 設計上必須考量應用程式設計者的需求。例如，函式的命名就會變得格外的重要。應用程式內部的函式或變數的命名，雖然也很重要，但和 API 的命名相較起來，API 的命名還更重要。因為 API 的使用者，即應用程式的設計者，是透過這些名稱在理解、運用 API 的。若是有不易懂、或是命名不一致的情況、……等等，就會造成應用程式開發者在學習、運用上的困難。

除了因應使用者對象的不同，需要考量的點不同之外。API 相較於應用程式中的程式碼，它的生存週期通常都比較長。

為什麼有些功能，我們會想要把它萃取出來放到 API 裡？主要原因之一是，它本身是特定領域的應用程式的共通需求。

因此，我們把它放到 API 中，就成了一個可以被重複使用的單元或模組，使得其他的應用程式開發者毋需再重新打造輪子了。也因為領域中的需求變動不會太快，所以通常我們都會期待已經做好的輪子可以撐久一點。

不過因為 API 是應用程式「介面」，在先天的本質上它就把抽象的介面和具象的實作給分離了，應用程式所倚賴的是介面而非實作。因此，只要介面保持不變，即使實作持續的在改變，也不會影響到應用程式中的客戶端程式碼。

而有了這樣的特質，使得應用程式和 API 可以平行發展，在 API 的介面設計、制定完成之後，可以透過先提供dummy 實作的方式，讓應用程式先行開發，毋需等待 API 的實作完成。此外，API 的實作也可以持續改良，都不會波及到應用程式中的客戶端程式碼。

更改API介面的影響很大，需謹慎並留意相容性

但是，這個「介面」雖然可以有效的阻隔 API 實作變更對客戶端程式碼的衝擊，但是，只要這個介面一旦發生變動，所產生的影響就會很大。因為所有的客戶端程式碼都是倚賴在這個介面上，介面的變動，意謂著所有倚賴它的客戶端程式碼，都得要做對應的審視及修改。所以 API 介面的變動是天大的事情。

相反的，應用程式中內部函式的變動影響就小多了，因為影響範圍僅侷限在應用程式裡，有找出受影響的程式碼就簡單多了。對那些應用程式愈多的 API 來說，小小的一個變動就可能讓一堆應用程式都面臨要修改的命運。因此，不得不審慎以對。但是，就像需求也會持續演化一樣，API 也是終究需要演化的，但是演化時，通常「向下相容性」會是最大的議題之一。有些 API，像 Windows API 或 Java Core API，基本上都維持著相當不錯的向下相容性，即使 API 的主要版本發生了變遷，也不會對舊有的程式碼瞬時造成立即性的影響。

前些日子在 Facebook 上，看到有應用程式開發者在抱怨他所使用的 API ，不但時常在介面上改版，而且還不能往下相容，因此造成了開發者很大的痛苦。這都是 API 設計者必須引以為戒的。

也因為 API 的改變是這麼重大的事情，所以身為 API 的設計者在設計介面時，需要花費更長的前置時間，來思考介面的設計及規畫。

因為，一旦介面定案、各個應用程式開始倚賴這組 API 開發後，日後，想要更動 API 介面的代價就會高很多。

此時，因為 API 的使用者可能是技術不純熟、或是對 API 理解不夠完備的設計者，所以 API 的實作必須要更穩固才行，就像是加入更多的「防呆措施」，因為應用程式設計者錯誤使用 API 的機會較高，必須預防在錯誤使用的情況下，不會造成更大的傷害。

開發應用程式的過程中，有可能也同時會面臨設計API的需求

在現在的開發工作中，許多團隊都會試著抽離跨專案、跨產品依然會共用的部份成為 API 組件，來得到開發上的好處。因此，在我們當中的許多人，或許不單只會扮演應用程式開發者的角色，也會做為 API 設計者的角色。

在本文中，我想試著說明二者的不同點，因此，當你有朝一日必須扮演 API 設計者的角色時，便可留意其中的差異，而能夠更稱職地扮演好 API 設計者的角色。