1951 年,Maurice Wilkes 在《電子數字計算機程序》中引入了最早的類似于 API 的概念,提出可重用的軟件例程來簡化 EDSAC 計算機的編程。

1968 – 首次提到“API”一詞(Ira W. Cotton)

1968 年,Ira W. Cotton 的論文《遠程計算機圖形學的數據結構與技術》首次使用“API”一詞,指的是用于遠程圖形處理的接口。

1974 – 首個數據庫 API(C. J. Date)

1974 年,C. J. Date 對比了關系數據庫和網絡數據庫兩種模型,重點討論了它們的程序編程接口 (API) 的差異,以促進數據庫交互。

1991 – CORBA 標準(Object Management Group)

1991 年,對象管理組 (OMG) 引入了 CORBA (公共對象請求代理架構) 標準,旨在實現不同系統和平臺之間分布式異構應用的通信。

1993 – CGI(Roy McCool)

1993 年,Roy McCool 開發了通用網關接口 (CGI),這是 Web 服務器與外部應用交互的早期標準,為現代 Web API 奠定了基礎。

2000 – Roy Fielding 提出 REST 理念

2000 年,Roy Fielding 的博士論文引入了 REST (表述性狀態轉移) 概念,為基于 Web 的應用定義了一種可擴展的無狀態架構。

2002 – Bezos 的 API 指令:推動微服務

2002 年,Jeff Bezos 在 Amazon 內部發布了一項指令,要求所有團隊通過服務接口 (API) 公開數據和功能,這為 Amazon 采用微服務架構和現代云計算奠定了基礎。

2010 – Flickr 的照片 API

2010 年,Flickr 的照片 API 允許開發者以編程方式訪問和操作用戶上傳的照片,實現了照片搜索、上傳、打標簽和元數據檢索等功能。

2015 – GraphQL(Meta Platforms)

2015 年,Meta Platforms (原 Facebook) 推出了 GraphQL,一種靈活的 API 查詢語言和運行時,允許客戶端只請求所需的數據,從而優化數據檢索并提高效率。

2016 – gRPC(Google)

2016 年,Google 推出了 gRPC,這是一種高性能、開源的遠程過程調用 (RPC) 框架,支持分布式系統之間的高效通信,利用 HTTP/2 和 Protocol Buffers 進行數據序列化。

對未來的推測

隨著 AI 的崛起:標準需同時適應人類與 AI

“Web 時代”的標準主要關注服務于人類用戶。可擴展性、緩存、安全性、易理解性和簡單性,都是我們人類關心的事物。這些對我們來說都是很重要的東西。

而現在,生產者和消費者中增加了新的“成員”——AI。在許多組織中,將有機器人團隊執行各種工作。未來的生態系統必須調整了,以便同時提高 AI 和人類的生產力。

API 需更易于被 AI 智能體發現和使用:HATEOAS 可能重回視野

Fielding 的論文提出了 HATEOAS (應用狀態的超媒體引擎) 概念,他想強調 API 的可發現性很重要。例如,在 API 的響應中,應該包含對消費者可用的其它資源的鏈接或引用。

這個想法沒有廣泛普及,但在 AI 智能體的參與下,這一概念可能會變得更為重要,因為許多 AI 可能會使用這些 API。這也意味著可以針對特定 AI 的需求生成“動態響應”。

編寫優秀的 API 文檔將更簡單、成本更低

在未來,我相信設計、測試和共享 API 的難題可以通過先進的 AI 工具輕松解決。

通過大語言模型 (LLM) 的理解能力,所有這些與 API 相關的問題都能得到解決。舉例來說,Hexmos 正在開發 LiveAPI,可通過最少的人為干預將任何代碼庫翻譯成友好實用的文檔頁面,我們已取得了良好效果。我們在這個領域才剛剛起步,所以我看到了未來的巨大改進潛力。

新 API 的推出速度將顯著加快

隨著 LLM 輔助的 IDE 的普及,可以肯定的是,開發新代碼和功能將需要:

這意味著每個“實現計劃”都可以大幅加速,從而實現更快的開發速度。

甚至設計和營銷也變得不那么繁瑣,從而加快了軟件產品,尤其是 API 的上市時間。

這意味著一件事:更多的實驗、更多的創新,因而市場上將涌現出更多可供試用的 API。

客戶端和服務器代碼自我升級:更具韌性的系統

很少有 API 能在一年內不出現故障。隨著時間推移,API 保持穩定性的可能性會大幅降低。即使是像 AWS 這樣的組織也常常會發生 API 中斷,造成問題。

問題的根源在于開發的自然周期:接口變更、版本不匹配、功能被移除或新增、溝通時有時無,等等因素。

在生產者和消費者之間,通常會有一個漫長的協商過程,逐步建立起新的共識。而隨著代碼庫的自動化發現和重構,用于“修復”這些不匹配的“協商”工作量可能會顯著減少。

新的 AI 經濟正在形成:組建“智能體團隊”維護新基礎設施

盡管 AI 目前尚未完全勝任獨立開發復雜軟件的任務,尤其是端到端的,但可以設想,AI 團隊可以幫助工程師維護新基礎設施和 API。它們可以理解客戶消息、協調和解決問題,甚至是修復補丁、升級系統等。

用于設計、實現、測試和共享 API 的新型機器人功能可能會涌現,我預測在這一領域將會發展出一個機器人經濟。

軟件變得更廉價:大多數 API 價格將下降

如上所述,隨著大量自動化技術的實現,軟件的“供給側”可能會超過“需求側”。你我都知道這意味著什么:在軟件開發和維護中,自動化和生產力的提升將導致軟件無處不在,供過于求必然會導致價格下降。當然,也可能會出現由更復雜系統驅動的新型 API,其成本可能比以往更高,但從整體上看,多數價格可能會走低。

即將出現情境感知 API:API 可“了解”用戶需求以調整響應

目前,API 的“輸入”和“輸出”往往是靜態的,通常只能處理少量有特定含義的字符串和數字片段。然而,未來的 API 輸入將會更加復雜。用戶的偏好、需求和具體情況可能會成為影響 API 的更重要的“輸入”。“我和我的情境”可能比任何其它特性更顯著地影響一個 API。在推薦算法等領域,這一趨勢已經在發展,但這些算法的生產和維護成本一直很高。不過,這類技術可能會逐漸商品化,并且可能會出現一些通用的結構來處理“上下文”。

結論

Fielding 的 REST 理論奠定了“Web 時代”的特征,而新的自動化浪潮作為“AI 時代”的一部分正在興起。API 的歷史顯示了通往當前狀態的痛苦而復雜之路。未來無疑將涉及一套新的競爭激烈的標準、錯誤的轉向等,直到新的穩定標準和“做事方式”出現。

本文章轉載微信公眾號@Finnova

上一篇:

一文讀懂API相關名詞

下一篇:

了解API端點:初學者指南
#你可能也喜歡這些API文章!

我們有何不同?

API服務商零注冊

多API并行試用

數據驅動選型,提升決策效率

查看全部API→
??

熱門場景實測,選對API

#AI文本生成大模型API

對比大模型API的內容創意新穎性、情感共鳴力、商業轉化潛力

25個渠道
一鍵對比試用API 限時免費

#AI深度推理大模型API

對比大模型API的邏輯推理準確性、分析深度、可視化建議合理性

10個渠道
一鍵對比試用API 限時免費