3. 接口设计原则:RESTful API设计规范、资源命名、HTTP方法选择
在资产台账移交接口开发中,遵循统一的接口设计原则是保障系统可维护性、可扩展性与团队协作效率的基础。本节围绕 RESTful API 设计规范,从资源命名、HTTP 方法选择、状态码使用三个核心维度展开,并结合资产移交场景给出具体示例。
3.1 RESTful API 设计规范概述
REST(Representational State Transfer)是一种基于资源的架构风格,核心约束包括:
- 无状态性:每个请求包含所有必要信息,服务端不保存客户端上下文。
- 统一接口:通过标准 HTTP 方法操作资源,资源通过 URI 唯一标识。
- 资源导向:将业务实体抽象为资源,而非操作或动作。
- 自描述消息:请求与响应中包含媒体类型、链接等信息,便于客户端理解。
资产移交场景适配: 移交单、资产项、质保记录、维护计划均视为独立资源,通过标准接口进行 CRUD 操作,避免使用 RPC 风格(如 /transferAsset?action=submit)。
3.2 资源命名规范
资源命名应遵循 名词复数形式、小写字母、连字符分隔 的原则,避免动词、下划线或驼峰命名。以下为资产移交场景的资源命名对照表:
| 业务实体 | 资源 URI | 说明 |
|---|---|---|
| 移交单 | /api/v1/transfer-orders |
移交主单据资源 |
| 移交资产项 | /api/v1/transfer-orders/{orderId}/assets |
子资源,嵌套于移交单下 |
| 维护计划 | /api/v1/maintenance-plans |
独立资源,与资产关联 |
| 质保记录 | /api/v1/warranty-records |
独立资源,可关联资产或移交单 |
| 资产台账 | /api/v1/assets |
核心资产主数据资源 |
命名避坑: 避免使用
/getTransferOrder、/transfer_order、/transferOrder 等非标准格式。统一使用 /transfer-orders 风格,便于前端和后端工具链自动处理。
3.3 HTTP 方法选择与语义
每个 HTTP 方法对应一种标准操作语义,在资产移交接口中应严格遵循:
| HTTP 方法 | 操作语义 | 幂等性 | 资产移交示例 |
|---|---|---|---|
| GET | 查询资源列表或单个资源 | 是 | GET /api/v1/transfer-orders?status=pending |
| POST | 创建新资源 | 否 | POST /api/v1/transfer-orders(创建移交单) |
| PUT | 全量更新资源 | 是 | PUT /api/v1/transfer-orders/{id}(更新整单) |
| DELETE | 删除资源 | 是 | DELETE /api/v1/transfer-orders/{id} |
| PATCH | 部分更新资源 | 否 | PATCH /api/v1/transfer-orders/{id}/status(更新状态) |
常见误区: 不要使用
POST 做查询操作,也不要用 GET 传递请求体。资产移交中涉及批量操作(如批量移交资产)时,应使用 POST 到集合资源,而非自定义 batchTransfer 端点。
3.4 接口设计原则流程关系
下图展示了资源命名、HTTP 方法与业务操作之间的映射关系,以及它们在资产移交流程中的位置:
3.5 接口设计示例:移交单创建与查询
以下代码展示符合 RESTful 原则的资产移交接口实现片段:
// 创建移交单(POST)
POST /api/v1/transfer-orders
Content-Type: application/json
{
"sourceDepartment": "IT运维部",
"targetDepartment": "资产管理中心",
"transferDate": "2025-06-01",
"assets": [
{"assetId": "AST-2025-001", "warrantyId": "WAR-001"},
{"assetId": "AST-2025-002", "warrantyId": "WAR-002"}
],
"maintenancePlanIds": ["MP-2025-01", "MP-2025-02"]
}
// 响应:201 Created
{
"id": "TO-2025-001",
"status": "draft",
"createdAt": "2025-06-01T10:30:00Z",
"_links": {
"self": {"href": "/api/v1/transfer-orders/TO-2025-001"},
"assets": {"href": "/api/v1/transfer-orders/TO-2025-001/assets"}
}
}
// 查询待处理移交单(GET)
GET /api/v1/transfer-orders?status=pending&page=1&size=20
// 响应:200 OK
{
"totalItems": 45,
"totalPages": 3,
"currentPage": 1,
"items": [
{
"id": "TO-2025-001",
"status": "pending",
"sourceDepartment": "IT运维部",
"targetDepartment": "资产管理中心",
"assetCount": 2
}
],
"_links": {
"next": {"href": "/api/v1/transfer-orders?status=pending&page=2&size=20"},
"prev": null
}
}
实践建议: 在响应中包含
_links 字段(HATEOAS 风格),帮助客户端发现关联资源,降低前后端耦合。例如移交单创建后返回资产子资源链接,客户端可直接通过该链接添加或移除资产项。
3.6 状态码使用规范
资产移交接口应使用标准 HTTP 状态码表达操作结果,避免自定义状态码:
| 场景 | HTTP 状态码 | 说明 |
|---|---|---|
| 查询成功 | 200 OK | GET 请求正常返回数据 |
| 创建成功 | 201 Created | POST 请求资源创建完成 |
| 更新成功 | 200 OK 或 204 No Content | PUT/PATCH 操作完成 |
| 删除成功 | 204 No Content | DELETE 操作完成,无返回体 |
| 请求参数错误 | 400 Bad Request | 缺少必填字段或格式错误 |
| 资源未找到 | 404 Not Found | 移交单 ID 不存在 |
| 冲突/重复创建 | 409 Conflict | 资产已存在于其他移交单 |
避坑提醒: 不要在所有成功响应中都返回 200,创建资源必须返回 201;不要使用 200 返回错误信息,应使用 4xx/5xx 状态码配合错误体描述。例如资产移交单重复提交时应返回 409,而非 200 + "error": "duplicate"。