3、路径与操作定义:路径模板、HTTP方法映射、operationId、summary、description、parameters、requestBody、responses
在 OpenAPI 规范中,路径(Path)与操作(Operation)是 API 契约的核心骨架。路径定义了资源的访问端点,操作则描述了在该端点上可执行的具体行为。本节将系统拆解路径模板、HTTP 方法映射、操作元数据(operationId、summary、description)以及请求/响应描述(parameters、requestBody、responses)的工程化定义方式。
3.1 路径模板与参数化
路径模板使用花括号 {} 声明动态路径参数,支持正则表达式约束。路径参数必须在 parameters 字段中显式定义,且 in: path 必须配合 required: true。
路径模板示例:
/api/v2/orders/{orderId}
/api/v2/orders/{orderId}/items/{itemId}
/api/v2/users/{userId}/tickets?status={status}
| 路径元素 | 说明 | 示例 |
|---|---|---|
{orderId} |
路径参数,必填,通常为 UUID 或整数 | a1b2c3d4-e5f6-7890-abcd-ef1234567890 |
{itemId} |
嵌套路径参数,表示子资源 | item_98765 |
?status={status} |
查询参数,可选,用于过滤 | pending |
路径模板避坑:路径参数名不能包含连字符或点号;路径模板不支持可选路径段(如
/users/{id?} 不合法),必须通过查询参数或拆分路径实现。
3.2 HTTP 方法映射与操作对象
每个路径下可定义多个 HTTP 方法(get、post、put、delete、patch、head、options、trace)。每个方法对应一个操作对象(Operation Object),包含完整的请求/响应描述。
3.3 operationId、summary 与 description
这三个字段构成操作的元数据层,直接影响 API 的可读性和工具链的自动化能力。
| 字段 | 约束 | 工程价值 | 示例 |
|---|---|---|---|
operationId |
全局唯一,仅含字母、数字、下划线 | 生成客户端方法名、日志追踪、监控指标标签 | getOrderById |
summary |
单行文本,不超过 120 字符 | API 文档列表摘要、Swagger UI 标题 | 根据订单ID获取订单详情 |
description |
支持 CommonMark Markdown | 详细使用说明、业务规则、错误码解释 | 返回订单的完整信息,包括商品列表、支付状态和物流跟踪号。 |
命名规范建议:operationId 采用
动词 + 名词 的驼峰格式,如 createUser、deleteTicket。避免使用 doSomething 或 processData 等模糊命名。
3.4 parameters:路径、查询、请求头与 Cookie
参数定义支持四种位置(in):path、query、header、cookie。每个参数必须指定 name、in、schema,路径参数还需 required: true。
parameters:
- name: orderId
in: path
required: true
schema:
type: string
format: uuid
description: 订单唯一标识
- name: status
in: query
required: false
schema:
type: string
enum: [pending, shipped, delivered, cancelled]
description: 按订单状态过滤
- name: X-Request-Id
in: header
required: false
schema:
type: string
description: 幂等请求标识,用于去重
| 参数位置 | 序列化方式 | 常见用途 | 必填性 |
|---|---|---|---|
path |
路径模板替换 | 资源标识符 | 始终 required |
query |
URL 查询字符串 | 过滤、排序、分页 | 可选 |
header |
HTTP 头部 | 认证令牌、幂等键、内容协商 | 按需 |
cookie |
Cookie 头部 | 会话标识、持久化偏好 | 按需 |
3.5 requestBody:请求体描述
适用于 POST、PUT、PATCH 方法。必须指定 content 字段,描述媒体类型和对应的 Schema。可选 required 标记请求体是否必须。
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- userId
- items
properties:
userId:
type: string
items:
type: array
items:
type: object
properties:
productId:
type: string
quantity:
type: integer
minimum: 1
application/xml:
schema:
$ref: '#/components/schemas/OrderRequest'
多媒体类型支持:requestBody 可同时声明
application/json、application/xml、multipart/form-data 等,客户端根据 Content-Type 头部选择。文件上传场景使用 multipart/form-data 并配合 type: string, format: binary。
3.6 responses:响应描述
每个操作必须至少定义一个成功响应(通常为 200、201 或 204)。响应对象包含 description 和 content,可定义多个状态码和媒体类型。
responses:
'201':
description: 订单创建成功
content:
application/json:
schema:
$ref: '#/components/schemas/OrderResponse'
'400':
description: 请求参数校验失败
content:
application/json:
schema:
$ref: '#/components/schemas/ErrorResponse'
'500':
description: 服务器内部错误
content:
application/json:
schema:
$ref: '#/components/schemas/ServerError'
3.7 完整操作定义示例
以下是一个完整的路径操作定义,整合了路径参数、查询参数、请求体和多状态码响应:
/api/v2/orders/{orderId}:
get:
operationId: getOrderById
summary: 根据订单ID获取订单详情
description: |
返回订单的完整信息,包括商品列表、支付状态和物流跟踪号。
如果订单不存在,返回 404 错误。
parameters:
- name: orderId
in: path
required: true
schema:
type: string
format: uuid
- name: includeItems
in: query
required: false
schema:
type: boolean
default: true
responses:
'200':
description: 成功返回订单数据
content:
application/json:
schema:
$ref: '#/components/schemas/Order'
'404':
description: 订单不存在
content:
application/json:
schema:
$ref: '#/components/schemas/NotFoundError'
'500':
description: 服务器内部错误
content:
application/json:
schema:
$ref: '#/components/schemas/ServerError'
Kafka 堆积诊断场景映射:在 Kafka 管理 API 中,路径
/api/v1/clusters/{clusterId}/topics/{topicName}/consumer-groups/{groupId}/lag 的 GET 操作可返回堆积深度、分区偏移量、消费者位移等指标,响应体中的 totalLag 字段直接用于告警阈值判断。