1、接口概述：什么是API、API的发展历史与微服务角色

说实话，我做了十几年后端，被问得最多的问题就是：「接口到底是个啥？」

每次听到这个问题，我都想反问一句：你点外卖的时候，是不是只跟外卖小哥打交道？你不需要知道餐厅后厨怎么炒菜、怎么装盘，你只需要告诉小哥你要什么，然后等着就行。

API 就是这个「外卖小哥」。

1.1 什么是 API？

API，全称 Application Programming Interface，翻译过来叫「应用程序编程接口」。名字挺唬人，但本质就一句话：它是两个软件系统之间约定的沟通方式。

我习惯把 API 拆成三个要素来理解：

• 端点（Endpoint）：你去哪里找它。比如 https://api.example.com/users
• 请求格式（Request）：你要说什么。比如 JSON 格式的 { "name": "张三" }
• 响应格式（Response）：它怎么回你。比如返回用户 ID、创建时间等

举个例子，你写了一个用户注册功能：

// 请求
POST /api/register
Content-Type: application/json

{
  "username": "alice",
  "password": "123456",
  "email": "alice@example.com"
}

// 响应
HTTP/1.1 201 Created
Content-Type: application/json

{
  "user_id": 10086,
  "username": "alice",
  "created_at": "2025-01-15T10:30:00Z"
}

你看，前端不需要知道后端用的是 MySQL 还是 PostgreSQL，也不需要知道密码是怎么加密的。它只管发这个格式的数据，拿到结果就行。这就是 API 的封装能力。

1.2 API 的发展历史：SOAP vs REST vs GraphQL

API 不是一天长成现在这样的。我入行那会儿，SOAP 还是主流，后来 REST 崛起，再后来 GraphQL 开始抢风头。咱们一个一个说。

1.2.1 SOAP 时代（1998 年 — 2010 年左右）

SOAP，全称 Simple Object Access Protocol。名字里带个「Simple」，但用过的人都知道，它一点都不 Simple。

SOAP 基于 XML，消息结构非常严格。一个请求长这样：

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <getUser>
      <userId>10086</userId>
    </getUser>
  </soap:Body>
</soap:Envelope>

我记得刚入行时，公司有个老系统就是用 SOAP 做的。每次调试都要装 SOAP UI，看那一大坨 XML 头都大。而且 SOAP 依赖 WSDL（Web Services Description Language）来描述接口，光生成 WSDL 文件就能折腾半天。

SOAP 的优点：安全性高、事务支持好、有严格的契约定义。金融、银行系统到现在还在用。

SOAP 的缺点：太重了。XML 解析慢、带宽占用大、学习曲线陡。说白了，杀鸡用牛刀。

1.2.2 REST 崛起（2010 年 — 至今）

REST，全称 Representational State Transfer。它不是一种协议，而是一种架构风格。

REST 的核心思想是：把一切操作都抽象成对「资源」的增删改查。用 HTTP 方法来表示动作：

HTTP 方法	操作	示例
GET	查询资源	GET /api/users/10086
POST	创建资源	POST /api/users
PUT	全量更新	PUT /api/users/10086
PATCH	部分更新	PATCH /api/users/10086
DELETE	删除资源	DELETE /api/users/10086

REST 为什么火？因为它轻量、直观、基于 JSON。你想想看，一个 GET 请求就能拿到数据，浏览器里直接就能测，多方便。

我在项目中遇到过很多团队，REST 接口设计得乱七八糟。比如把操作动词塞进 URL：GET /api/deleteUser?id=1。这哪是 REST，这是 RPC 披着 REST 的皮。

1.2.3 GraphQL 登场（2015 年 — 至今）

GraphQL 是 Facebook 在 2015 年开源的一种查询语言。它解决了一个 REST 的痛点：数据过取和欠取。

举个例子，你用 REST 查用户信息，接口返回 20 个字段，但你只需要用户名和邮箱。没办法，全得收下来。GraphQL 让你可以精确指定要什么：

// GraphQL 查询
query {
  user(id: 10086) {
    username
    email
  }
}

// 返回结果
{
  "data": {
    "user": {
      "username": "alice",
      "email": "alice@example.com"
    }
  }
}

你看，只返回了两个字段。前端想要什么自己定，后端不用为每个页面单独写接口。

但 GraphQL 也不是银弹。它的缓存机制比 REST 复杂，查询深度控制不好容易把数据库打爆。我见过一个团队，GraphQL 查询嵌套了 7 层，一次请求触发了上百条 SQL，数据库直接挂了。

1.2.4 三种风格对比

维度	SOAP	REST	GraphQL
数据格式	XML	JSON / XML	JSON
协议	HTTP / SMTP / JMS	HTTP	HTTP
学习成本	高	低	中
性能	低（XML 解析慢）	高	中（需解析查询）
缓存	难	容易（HTTP 缓存）	较复杂
适用场景	金融、银行、企业级	Web 应用、移动端	复杂数据、多端适配

1.3 接口在微服务架构中的角色

微服务架构，说白了就是把一个大系统拆成一堆小服务。每个服务独立部署、独立开发、独立扩展。

那问题来了：服务之间怎么通信？

答案就是：接口。

在微服务架构里，接口承担了三个核心角色：

1. 服务间通信的桥梁：订单服务要查用户信息，不能直接连用户数据库，只能调用户服务的 API。
2. 服务治理的边界：每个服务通过接口暴露能力，内部实现随便改，只要接口不变，其他服务不受影响。
3. 流量管控的关卡：限流、熔断、降级，都是在接口层做的。

我画了一张图，帮你理解微服务架构中接口的位置：

从这张图你能看到：

• API 网关是统一入口，负责路由、认证、限流。客户端只跟网关打交道，不直接调服务。
• 服务间接口（红色虚线）是内部通信。比如订单服务要查用户信息，就调用户服务的接口。
• 每个服务独享数据库，不直接访问其他服务的库。这是微服务的一个核心原则。

我在实际项目中见过不少团队，微服务拆了，但数据库没拆。结果一个服务改了表结构，其他服务全挂了。嗯，这里要注意：微服务架构里，接口就是你的防火墙。只要接口稳定，内部随便折腾。