原文：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 的历史显示了通往当前状态的痛苦而复杂之路。未来无疑将涉及一套新的竞争激烈的标准、错误的转向等，直到新的稳定标准和"做事方式"出现。