← 返回示例
编程与数据 · 示例 26
设计一个不容易返工的 API
先定资源和错误码，再写接口。
适用场景
要设计前后端接口，担心字段和错误处理反复改。
原始需求
帮我设计一个 API。
可直接复制的提示词
请帮我设计一个 HTTP API。
业务：【一句话】
调用方：【前端 / 第三方 / 内部服务】
核心资源：【】
关键操作：【增删改查/批量/搜索】
要求：
1. 先列资源和 URL；
2. 给出请求/响应示例；
3. 定义错误码和错误结构；
4. 说明分页、过滤、幂等怎么做；
5. 指出 3 个未来可能扩展、但现在不要过度设计的地方。为什么有效
- 先资源后接口，结构更稳定。
- 错误结构统一，前端好处理。
- 明确不要过度设计，避免复杂。
可替换变量
- 认证方式。
- 数据量/分页需求。
- 是否需要版本化。
常见失败
- URL 用动词。
- 错误码不统一。
- 一开始就设计过度复杂的权限。
适用模型：ChatGPT、Claude、DeepSeek