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 分页,避免深度翻页性能劣化。
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 条运单),验证请求头、响应结构、分页元数据、错误码格式是否与本文规范一致。任何偏离都应视为契约不匹配,需在集成测试阶段修复。