3. OpenAPI 文档结构:五大核心对象
一份标准的 OpenAPI 文档(通常为 JSON 或 YAML 格式)由五个顶层对象构成其骨架。理解这五个对象的职责与层级关系,是编写高质量接口契约的基础。本章将逐一拆解 info、servers、paths、components 和 tags 对象的结构与使用规范。
核心原则:OpenAPI 文档的顶层对象顺序没有强制要求,但业界惯例按 info → servers → tags → paths → components 排列,以提升可读性。
3.1 info 对象:API 元数据
info 对象是文档的“身份证”,提供 API 的基本描述信息。它是唯一一个必须存在的顶层对象。
| 字段 | 类型 | 必需 | 说明 |
|---|---|---|---|
| title | string | 是 | API 名称,如“用户管理服务” |
| version | string | 是 | 文档版本号,建议遵循语义化版本(如 1.0.0) |
| description | string | 否 | API 详细描述,支持 CommonMark 语法 |
| termsOfService | string | 否 | 服务条款 URL |
| contact | object | 否 | 联系人信息(name、url、email) |
| license | object | 否 | 许可证信息(name、url) |
info:
title: 电商订单服务 API
version: 2.1.0
description: 提供订单创建、查询、退款等核心能力
contact:
name: API 支持团队
email: api-support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0
最佳实践:version 字段应随 API 变更递增,不要与实现版本耦合。description 中可包含 Markdown 格式的快速入门链接或使用限制。
3.2 servers 对象:连接端点
servers 对象定义 API 的基础 URL 列表。每个 server 包含 url(必需)和 description(可选),支持变量模板。
servers:
- url: https://api.example.com/v2
description: 生产环境
- url: https://staging-api.example.com/v2
description: 预发布环境
- url: http://localhost:8080/api/v2
description: 本地开发环境
当使用变量模板时,可在 variables 中声明默认值:
servers:
- url: https://{environment}.example.com/{version}
variables:
environment:
default: api
enum: [api, staging, dev]
version:
default: v2
注意:如果未定义 servers,工具默认使用
http://localhost。生产文档务必显式声明 servers,避免误用。
3.3 paths 对象:API 端点与操作
paths 是文档的核心,以相对路径为键,映射到该路径支持的 HTTP 方法(get、post、put、delete、patch 等)。每个操作可定义 parameters、requestBody、responses 等。
paths:
/orders:
get:
summary: 获取订单列表
parameters:
- name: status
in: query
schema:
type: string
responses:
'200':
description: 成功返回订单列表
content:
application/json:
schema:
type: array
items:
$ref: '#/components/schemas/Order'
post:
summary: 创建新订单
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateOrderRequest'
responses:
'201':
description: 订单创建成功
| 路径元素 | 说明 | 示例 |
|---|---|---|
| 静态路径 | 固定字符串,无参数 | /health |
| 路径参数 | 用花括号包裹,运行时替换 | /orders/{orderId} |
| 查询参数 | 定义在 parameters 中,in: query | ?page=1&size=20 |
| 请求体 | 仅用于 post/put/patch | JSON Schema 描述 |
| 响应 | 按 HTTP 状态码组织 | 200、404、500 |
3.4 components 对象:可复用组件仓库
components 是文档的“工具箱”,集中管理可复用的 Schema、参数、响应、请求体、安全方案等。通过 $ref 引用,避免重复定义。
components:
schemas:
Order:
type: object
properties:
id:
type: integer
total:
type: number
status:
type: string
enum: [pending, paid, shipped]
CreateOrderRequest:
type: object
required: [productId, quantity]
properties:
productId:
type: integer
quantity:
type: integer
minimum: 1
parameters:
orderIdParam:
name: orderId
in: path
required: true
schema:
type: integer
responses:
NotFound:
description: 资源未找到
content:
application/json:
schema:
type: object
properties:
message:
type: string
引用语法:
$ref: '#/components/schemas/Order' 表示引用 components 下 schemas 中的 Order 定义。路径以 # 开头,使用 JSON Pointer 语法。
3.5 tags 对象:文档分组与导航
tags 对象为路径操作提供逻辑分组。每个 tag 包含 name(必需)和可选的 description。在 paths 中通过 tags 字段关联。
tags:
- name: 订单
description: 订单创建、查询、退款操作
- name: 商品
description: 商品信息与库存管理
- name: 用户
description: 用户认证与资料管理
paths:
/orders:
get:
tags: [订单]
summary: 获取订单列表
/products:
get:
tags: [商品]
summary: 获取商品列表
tags 在文档工具(如 Swagger UI)中会生成分组标题,提升可读性。一个操作可以关联多个 tag。
3.6 对象层级速查表
| 对象 | 必需性 | 主要子字段 | 典型用途 |
|---|---|---|---|
| info | 必需 | title, version, description | API 标识与版本管理 |
| servers | 可选 | url, description, variables | 多环境连接配置 |
| paths | 必需 | /{path}: {http方法} | 定义所有 API 端点 |
| components | 可选 | schemas, parameters, responses | 共享类型与模型 |
| tags | 可选 | name, description | 文档分组与导航 |
实战建议:在项目初期先定义 info 和 tags,让团队对 API 范围和分组达成共识;再逐步填充 paths 和 components。servers 可在部署阶段再完善。