原文：https://journal.hexmos.com/rest-turns-25/
原題：REST APIs Turn 25: How They Came To Be and What Could Be Next
作者：Shrijith Venkatramana
翻譯：豌豆花下貓&ChatGPT
根本問題：新興的“AI 時代”將如何影響“Web 時代”的產物？
2000 年，Roy Fielding 在博士論文中，正式引入了“表述性狀態轉移” （Representational State Transfer，簡稱 REST）這一概念。隨著 2024 年接近尾聲，REST 的概念也即將迎來至少 25 歲了。我稍後會詳細介紹，REST 的這 25 年是如何成為了“Web 時代”的特徵。
隨著“ChatGPT 演示”現象的出現，以及 AI 和自動化所帶來的新樂觀情緒，我希望重新審視 API，特別是 RESTful API 的歷史。在文章的最後，我會對未來“AI 時代”中的 API 領域做一些大膽的猜測。
我對歷史感興趣，因為它為我們指明未來的方向
提醒讀者：Fielding 的論文在“REST API”普及全球之前就已經完成了。Fielding 僅將“REST”作為在 HTTP 上構建“分散式超媒體”的架構風格之一（更像是 HTTP 的擴充套件）。因此，他對這一主題的表述相當抽象和微妙。
在本文中，我不打算詳盡複述 Fielding 的觀點，而是重點回顧在引入 REST 之前和之後的 API 發展歷程，透過對比來更清晰地瞭解 API 的發展。我會更關注 API 的實際應用演變，而非其背後的學術理論。
為什麼要研究歷史？因為這有助於更清楚地瞭解 API 及其未來可能的演變方向。本文更多是一種個人對該主題的探索，而非嚴謹的學術研究。
REST 的核心：描述“Web 時代”的需求
在 Fielding 開始創作他的論文時：
- Web 已經出現了約 10 年。
- 它積累了一套標準和“運作方式”。
- Fielding 試圖透過深入研究擴充套件、快取、元件分割槽、通訊和 Web 演變需求，避免有害的架構。
- 重點在於收集一系列“架構約束”以構建“架構風格”。
- Fielding 的研究成果直接應用於 HTTP 和 URL 標準的改進。
- 作為一種架構模式，REST 考慮了多個屬性，包括元件互動的擴充套件性、通用介面、元件的獨立部署、延遲、安全性和向後相容性等。
API 歷史的快速概覽
1951 - 最早的 API，但未明確稱呼（Maurice Wilkes）
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 的歷史顯示了通往當前狀態的痛苦而複雜之路。未來無疑將涉及一套新的競爭激烈的標準、錯誤的轉向等，直到新的穩定標準和“做事方式”出現。
延伸閱讀
- API 設計，第一部分：REST 之前的時代 – Chelsea Troy
- Roy Fielding 的 REST 論文被濫用