# 1. RESTful API 设计规范的核心约束中资源命名、HTTP 方法语义、状态码使用、版本化策略如何统一？ A 资源用动词命名 B GET 可以改状态 C 资源用复数名词、HTTP 方法语义（GET/POST/PUT/DELETE）分明、状态码准确、版本化统一，用 OpenAPI lint + 评审强制 ✓ 正确答案 D 版本化随意
# 2. API 的向后兼容承诺与破坏性变更管理中字段废弃（deprecation）流程如何设计？ A 字段可直接删除 B 新增替代字段 → 标记 deprecated → 通知迁移 → major 移除，旧字段保留一个 major 周期，用 diff 检测防止意外破坏 ✓ 正确答案 C 破坏性变更可在 minor 进行 D 废弃字段无需提示
# 3. RESTful API 的资源建模中嵌套资源、操作语义与版本策略如何设计？ A 资源用名词、嵌套表达从属（≤2 层）、非 CRUD 动作用动作资源，版本统一并向后兼容，风格一致 ✓ 正确答案 B 资源路径用动词 C 嵌套越深越好 D 动作直接塞进资源路径
# 4. REST 与 RPC 风格混用的治理中同一系统内哪些接口保持资源式（REST）、哪些采用动作式（RPC endpoint），边界规范如何防止风格漂移与团队认知分裂？ A 所有接口都用 REST B 风格随意切换 C 所有接口都用 RPC D 资源型面向外部用 REST，动作型内部调用用 RPC，边界规范 + 评审 + lint 防漂移，风格决策集中防认知分裂 ✓ 正确答案
# 5. API 版本管理（URL/Header/内容协商三种）的取舍与向后兼容策略？ A URL 显式（公共 API）、Header 灵活（内部）、内容协商语义化（复杂），选一种统一，旧版本保留走 deprecation，遵循 SemVer ✓ 正确答案 B 所有 API 都用 URL 版本 C 版本化随意 D 版本化与向后兼容无关
# 6. API 幂等性设计规范中哪些接口必须幂等？幂等键如何约定？ A GET/PUT/DELETE 天然幂等，POST（创建/动作）用 Idempotency-Key 去重并返回首次结果，防止重复支付/下单 ✓ 正确答案 B 所有接口都天然幂等 C POST 天然幂等 D 幂等键无需有效期
# 7. 分页、排序、过滤参数的统一约定与游标分页 vs 偏移分页的规范选择？ A 所有分页都用偏移分页 B 游标分页适合所有场景 C 统一参数约定（page/size/cursor/sort/filter），中小数据用偏移分页，大数据/实时用游标分页（keyset），按场景选择 ✓ 正确答案 D 分页参数随意
# 8. API 错误模型中错误码、错误消息、字段级错误（field errors）与重试头（Retry-After）的规范化设计？ A 错误响应只有 message B 错误无结构可解析 C 统一错误体（code/message）+ 字段级错误（fieldErrors 供表单定位）+ Retry-After（限流重试），错误码字典集中 ✓ 正确答案 D 字段级错误不需要
# 9. GraphQL 与 REST 的 API 设计取舍，schema 演进与向后兼容如何保障？ A GraphQL 适合所有场景 B REST 适合所有场景 C GraphQL 适合按需取数/复杂查询，REST 适合资源语义/缓存；schema 演进"只加不改"，废弃用 @deprecated，删除要 major ✓ 正确答案 D schema 可随意删除字段
# 10. API 乐观并发控制的规范选择中 ETag/If-Match、版本号字段、Last-Modified 三种机制的适用场景与团队统一约定如何制定？ A 所有接口都用 Last-Modified B 并发控制无需规范 C 版本号字段适合所有场景 D ETag/If-Match（HTTP 标准，412）、版本号字段（显式业务，409）、Last-Modified（粗粒度缓存），团队统一选一种并约定冲突状态码 ✓ 正确答案
# 11. API 规范在代码评审中的落地中如何把 API 设计规范固化为评审 checklist、契约测试与自动化校验（OpenAPI lint、breaking change 检测）？ A 只靠评审者自觉遵守规范文档 B 只写规范文档，不校验 C 用评审 checklist + 契约测试 + OpenAPI lint/breaking change 检测三层手段，并将自动化校验纳入 CI 门禁 ✓ 正确答案 D 取消评审，完全依赖自动化
# 12. API 字段设计规范中命名（snake_case vs camelCase）、可空性、枚举扩展性与时间/金额表示（ISO 8601、最小货币单位）如何统一？ A 命名统一、可空性显式、枚举可扩展、时间用 ISO 8601、金额用最小货币单位整数，消除跨语言歧义 ✓ 正确答案 B 金额用 double 表示，简单高效 C 时间用本地时间字符串即可 D 枚举值用数字并允许随意变更
# 13. API 的一致性治理中如何维护 API 清单与所有权（owners），跨团队新增 API 的评审与注册流程如何设计？ A 每个团队自行新增 API，无需登记 B 用 API 清单记录、明确 owner、经评审后注册，并用 CI 门禁强制新 API 有 owner 且符合规范 ✓ 正确答案 C API 无需 owner，谁都能改 D 清单维护一次即可，不用更新
# 14. 版本化策略与淘汰中 API 生命周期（预览→正式→弃用→移除）的窗口与通知机制，废弃字段如何通过响应头与文档提示迁移？ A 直接下线旧接口，不通知 B 弃用后立即移除 C 生命周期分预览/正式/弃用/移除，各阶段有窗口与通知，废弃字段用 Deprecation/Sunset 响应头与文档提示迁移，调用量归零后再移除 ✓ 正确答案 D 废弃字段无需提示
# 15. API 可观测性规范中请求 ID、结构化错误与调用方标识如何作为 API 规范的一部分，支撑链路追踪与服务商责任界定？ A 用 requestId 支撑链路追踪、clientId 支撑责任界定、结构化错误统一响应格式，并写入 API 规范作为契约 ✓ 正确答案 B 错误响应格式随意，各服务自定 C 请求 ID 仅内部使用，无需返回 D 无需调用方标识
# 16. OpenAPI 规范在 code-first vs design-first 团队的工程价值 A code-first 以代码为源生成契约、适合快速迭代；design-first 以契约为源驱动开发、适合多方协作；关键是确立单一事实来源 ✓ 正确答案 B 两种方式 OpenAPI 都无价值 C design-first 必然优于 code-first D code-first 无法生成契约
# 17. GraphQL/REST/tRPC 接口设计选择决策点 A REST 通用成熟、GraphQL 按需灵活、tRPC 全栈类型安全快；按是否对外、团队栈、字段灵活性、缓存需求决策 ✓ 正确答案 B 三种方式完全等价，随意选择 C tRPC 适合对外公开 API D GraphQL 缓存最简单
# 18. gRPC/Protobuf 的字段编号管理与 reserved 关键字在兼容性中的作用？ A 字段编号可随意更改，不影响兼容 B 字段编号一旦发布不可变，删除字段用 reserved 保留编号/名字，防止复用破坏新旧数据兼容 ✓ 正确答案 C reserved 只影响文档，不影响序列化 D 字段名比编号更重要，编号可复用
# 19. API 网关层的统一规范落地中鉴权、限流、CORS、请求 ID 注入如何作为 API 设计规范的一部分在网关层强制，与业务侧规范的边界在哪？ A 鉴权/限流/CORS/请求 ID 等横切关注点在网关统一强制，业务侧管业务语义；粗粒度鉴权在网关、细粒度授权在业务 ✓ 正确答案 B 网关承担所有业务逻辑 C 业务侧重复实现鉴权、限流、CORS D 网关不处理任何横切关注点
