ToB企服应用市场:ToB评测及商务社交产业平台

标题: REST API 已经 25 岁了：它是如何形成的，将来可能会怎样？ [打印本页]
作者: 没腿的鸟    时间: 2024-11-15 18:05
标题: REST API 已经 25 岁了：它是如何形成的，将来可能会怎样？
原文：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 开始创作他的论文时：
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 的历史显示了通往当前状态的痛苦而复杂之路。未来无疑将涉及一套新的竞争激烈的标准、错误的转向等，直到新的稳固标准和“办事方式”出现。
延伸阅读


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4