4. 请求与响应结构设计:统一请求格式、响应体规范、错误码体系设计、分页与排序标准

在承运商集成场景中,API 的请求与响应结构是系统间通信的“通用语言”。缺乏统一规范将导致集成方适配成本激增、调试困难、错误处理混乱。本章围绕四个核心维度——统一请求格式、响应体规范、错误码体系、分页与排序标准——建立企业级 RESTful API 契约。

4.1 统一请求格式

所有面向承运商的 API 请求应遵循一致的 HTTP 方法和头部约定,减少集成方的学习成本。

维度 规范要求 说明
HTTP 方法 GET / POST / PUT / PATCH / DELETE 严格对应查询、创建、全量替换、部分更新、删除操作
Content-Type application/json 统一使用 JSON 格式,避免 XML 或 form-data 混用
Accept application/json 客户端必须声明可接受的响应格式
请求 ID X-Request-ID (UUID) 用于全链路追踪,服务端必须在响应中回传
时间戳 X-Timestamp (ISO 8601) 客户端请求发起时间,用于防重放与延迟监控
认证令牌 Authorization: Bearer <> 所有请求必须携带有效的 JWT 或 OAuth2
最佳实践: 对于 POST/PUT 请求体,必须包含 apiVersion 字段(如 "1.0"),以便服务端在向后兼容时进行版本路由。

4.2 响应体规范

响应体采用三层封装结构:状态层、数据层、元数据层。所有响应(包括错误)均遵循此契约。

{
  "status": {
    "code": 200,
    "message": "Success",
    "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
  },
  "data": {
    // 业务数据对象或数组
  },
  "meta": {
    "timestamp": "2025-03-21T10:30:00Z",
    "apiVersion": "1.0",
    "pagination": { }  // 仅分页响应时出现
  }
}
层级 字段 类型 必填 说明
status code int 是 HTTP 状态码 + 业务扩展码(见 4.3)
message string 是 人类可读的状态描述
requestId string 是 与请求头 X-Request-ID 一致
data — object/array 否 业务主体;错误时可为 null
meta timestamp string 是 服务端响应生成时间 (ISO 8601)
apiVersion string 是 当前响应使用的 API 版本
pagination object 条件 分页响应时必填
设计要点: status.code 不等于 HTTP 状态码。例如,业务层面“运单已存在”应返回 409 HTTP 状态码,但 status.code 可定义为 40901,其中 01 为业务子码,便于客户端精确处理。

4.3 错误码体系设计

错误码采用 5 位数字分段编码:前 3 位对应 HTTP 状态码大类,后 2 位为业务细分码。所有错误响应必须包含 errors 数组,提供可操作的错误详情。

{
  "status": {
    "code": 42203,
    "message": "Validation Failed",
    "requestId": "b2c3d4e5-f6a7-8901-bcde-f12345678901"
  },
  "data": null,
  "meta": {
    "timestamp": "2025-03-21T10:30:05Z",
    "apiVersion": "1.0"
  },
  "errors": [
    {
      "field": "shipment.weight",
      "code": "INVALID_VALUE",
      "message": "Weight must be between 0.1 and 50000 kg"
    },
    {
      "field": "shipment.dimensions.length",
      "code": "MISSING_REQUIRED",
      "message": "Length is required when volume weight is calculated"
    }
  ]
}
错误码范围 HTTP 状态码 含义 典型场景
40001 – 40099 400 请求格式错误 JSON 解析失败、缺少必填头
40101 – 40199 401 认证失败 过期、签名无效
40301 – 40399 403 授权不足 无承运商权限、IP 白名单拒绝
40401 – 40499 404 资源不存在 运单号未找到、路由不存在
40901 – 40999 409 资源冲突 重复创建、状态冲突
42201 – 42299 422 业务校验失败 字段值越界、关联数据不完整
42901 – 42999 429 限流触发 超出 QPS 配额、并发超限
50001 – 50099 500 服务端内部错误 数据库超时、第三方接口异常
50301 – 50399 503 服务暂不可用 维护中、过载降级
避坑指南: 不要在错误消息中暴露堆栈跟踪、数据库细节或内部 IP。生产环境错误消息应面向集成方,而非开发者调试。建议在 errors[].code 中使用枚举字符串(如 INVALID_VALUE),而非数字码,便于客户端做精确匹配。

4.4 分页与排序标准

所有列表查询接口必须支持统一的分页和排序参数,避免每个接口各自定义 page、limit、offset 等混乱命名。

4.4.1 请求参数

参数 类型 默认值 说明
page int 1 页码,从 1 开始
size int 20 每页记录数,最大值 100
sort string createdAt:desc 排序字段与方向,逗号分隔多字段
GET /api/v1/shipments?page=2&size=50&sort=status:asc,createdAt:desc

4.4.2 响应分页元数据

"pagination": {
  "page": 2,
  "size": 50,
  "totalElements": 1234,
  "totalPages": 25,
  "hasNext": true,
  "hasPrevious": true
}
字段 类型 说明
page int 当前页码
size int 当前页实际记录数(可能小于请求的 size)
totalElements long 总记录数
totalPages int 总页数
hasNext bool 是否有下一页
hasPrevious bool 是否有上一页

4.4.3 排序语法

sort 参数格式:字段名:方向,多个排序条件用逗号分隔。方向仅支持 asc 或 desc。允许排序的字段必须在 API 文档中显式声明,避免对未索引字段排序导致性能问题。

性能建议: 对于承运商高频查询(如按运单号、按日期范围),建议在数据库层建立覆盖索引,并限制 size 最大值为 100。超过 100 条的分页请求应使用游标分页(cursor-based pagination)替代传统 offset 分页,避免深度翻页性能劣化。
承运商集成 RESTful API 请求与响应结构总览 统一请求格式 • HTTP 方法:GET / POST / PUT / PATCH / DELETE • Content-Type:application/json • 请求头:X-Request-ID / X-Timestamp • 认证:Authorization: Bearer <> • 请求体:apiVersion + 业务字段 统一响应体规范 • status:code / message / requestId • data:业务主体(对象或数组) • meta:timestamp / apiVersion • pagination(分页时必填) • errors(错误时返回) 请求 → 响应 错误码体系设计 • 5 位数字分段:HTTP 状态码 + 业务子码 • 错误响应包含 errors[] 数组 • 枚举字符串 code(如 INVALID_VALUE) 分页与排序标准 • 请求参数:page / size / sort • 响应元数据:totalElements / totalPages • 排序语法:字段名:asc 或 字段名:desc 核心设计原则 1. 所有响应(含错误)必须包含 status 层,确保客户端可统一解析。 2. 分页参数命名统一,禁止各接口自定义 pageNo / pageSize / limit 等变体。

4.5 实战案例:运单列表查询接口

以下是一个完整的请求-响应示例,展示上述规范在真实承运商集成中的落地效果。

请求示例

GET /api/v1/shipments?page=1&size=20&sort=createdAt:desc
Headers:
  Content-Type: application/json
  Accept: application/json
  X-Request-ID: f47ac10b-58cc-4372-a567-0e02b2c3d479
  X-Timestamp: 2025-03-21T10:30:00Z
  Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

响应示例

{
  "status": {
    "code": 200,
    "message": "Success",
    "requestId": "f47ac10b-58cc-4372-a567-0e02b2c3d479"
  },
  "data": [
    {
      "shipmentId": "SHP202503210001",
      "status": "IN_TRANSIT",
      "weight": 120.5,
      "origin": "CNHKG",
      "destination": "USLAX",
      "createdAt": "2025-03-21T08:15:00Z"
    }
  ],
  "meta": {
    "timestamp": "2025-03-21T10:30:01Z",
    "apiVersion": "1.0",
    "pagination": {
      "page": 1,
      "size": 20,
      "totalElements": 156,
      "totalPages": 8,
      "hasNext": true,
      "hasPrevious": false
    }
  }
}
集成检查清单: 在对接承运商 API 时,建议集成方先调用一个简单的列表接口(如查询最近 10 条运单),验证请求头、响应结构、分页元数据、错误码格式是否与本文规范一致。任何偏离都应视为契约不匹配,需在集成测试阶段修复。