软件之间通信的结构化方式。在AI领域，这通常意味着将请求（您的提示）发送到提供商的服务器，并接收响应（模型的输出）。REST API通过HTTPS是标准。
每家AI提供商—Anthropic、Google、Mistral—都通过API提供其模型。如果你正在构建任何超出聊天窗口的AI应用，你就是在使用API。
在机械层面，一个AI API调用只是一个HTTP请求—几乎总是向HTTPS端点发送带有JSON正文的POST请求。您发送提示、系统指令、模型参数（如温度和最大token数），然后提供商返回包含模型输出的JSON响应。目前大多数提供商都遵循OpenAI设定的模式：一个类似/v1/chat/completions的端点，接受包含角色/内容对的消息数组。Anthropic的Messages API在结构上略有不同，但遵循相同的哲学。需要理解的关键点是，这些调用是无状态的—除非每次显式重新发送对话历史记录，否则服务器不会记住您的上一次请求。
流式传输是更有趣的部分。您无需等待模型生成完整响应（长回答可能需要10-30秒），大多数AI API支持服务器发送事件（SSE）。服务器在生成过程中逐个发送响应token，因此用户几乎立即就能看到文本。这就是为什么即使完整响应需要较长时间，ChatGPT和Claude仍显得响应迅速—您能实时看到模型“思考”的过程。正确实现流式传输意味着处理部分JSON片段、管理连接超时，并在流式传输中断时优雅地恢复。
身份验证方式因提供商而异，但通常分为两种模式：一种是作为授权头中Bearer令牌传递的简单API密钥，另一种是企业环境中更复杂的OAuth流程。Anthropic使用x-api-key头，OpenAI使用Authorization: Bearer sk-...，而Google Cloud需要服务账户凭证。如果您正在使用多个提供商（大多数生产系统都是如此），您会很快发现“OpenAI兼容”是一个光谱。Together AI、Groq和Mistral等提供商大多遵循OpenAI的模式，但错误处理、参数支持和响应格式的边缘情况才是集成工作的实际所在。
需要澄清的一个误解：尽管REST API占主导地位，但它们并不是唯一的选择。一些提供商提供用于低开销通信的gRPC端点，而基于WebSocket的API在实时语音和流媒体用例中越来越常见。例如，ElevenLabs的语音API使用WebSocket进行双向音频流式传输。但对于文本输入文本输出的LLM推理，带有SSE流式传输的REST仍是标准，短期内不太可能改变—与模型生成token所花费的时间相比，HTTP的开销可以忽略不计。