Windows應用程式設計接口。API是一個程式內（或一組相關程式內）的一組函式調用，程式設計師用它創建其他程式。不必知道函式內部，只要知道函式原型及返回值。
基本介紹
- 中文名：API應用程式設計接口
- 外文名：API
- 平台：Windows
- 性質：設計接口
API定義,API設計原則,API敏捷性,API設計注意事項,
API定義
Windows應用程式設計接口。API是一個程式內（或一組相關程式內）的一組函式調用，程式設計師用它創建其他程式。不必知道函式內部，只要知道函式原型及返回值。將一組函式轉入API的問題實質是此函式提供每個人可使用的技術規範資料。Windows API大概是今天世界上最著名的API了。現在API已發展到了Win32 API。在它的核心中，依靠三個主要組件提供Windows的大部分函式。這三個組件分別是USER32.DLL、GDI32.DLL、KERNEL32.DLL。
API是指一組函式或例程，它們用於完成特定任務或提供簡單方法來與軟體組件進行互動，通常允許自動化常見流程，例如與在其他機器上運行的伺服器進行互動。
API可以是一個庫，其中包括例程、數據結構、對象類和變數的規格，或者只是暴露給API使用者的遠程調用的規格。一些API是基於國際標準（可移植作業系統接口），而另一些則是以開源或供應商文檔形式公之於眾。
API設計原則
- 驗證所有元素：對API的所有屬性提出疑問。
- 不走捷徑：除非通過API公開，否則這些外部系統式無法訪問任何其他系統。
- 無打包設計：外部客戶不會在乎該服務是否有主機作為幕後支持、APP伺服器中是否包含Java代碼或者node.js腳本。如果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相去甚遠。
