用途：帮助设计与评审 REST API，使其符合面向开发者客户端的标准约定，而非暴露内部数据模型。核心工作流：识别资源（名词、复数、嵌套不超过两层），将操作映射到 HTTP 动词与状态码，提前定义分页、过滤、错误信封和认证，并为每个端点编写可复制的 curl 示例。
主要能力：URI 规则（复数名词、路径版本如 /v1/orders、最多两层嵌套、大小写一致、动作端点少见且限定范围）；动词与 CRUD 映射（GET 安全幂等，POST 创建返回 201 与 Location，PUT 整体替换，PATCH 部分更新，DELETE 返回 204）；状态码区分（400 表示格式合法但操作非法，422 表示格式或校验失败）；响应信封二选一（裸返回或统一包裹，全项目一致）；错误信封可选用 OAuth2 风格或 RFC 7807 Problem Details；分页可选 HTTP Range 语义或游标分页（limit+1 技巧、不透明游标）；过滤、排序、搜索采用 CSV 多值、- 前缀降序、min_/max_ 前缀、_after/_before 后缀；expand/include、字段裁剪、HATEOAS（Link 头或 _links）。
使用方式与限制：安全要求 OAuth2 + HTTPS，Bearer JWT 或 OIDC，按端点 scope 最小权限；非幂等操作接受 Idempotency-Key 请求头，缓存 2xx 与 4xx 约 24 小时；返回 X-RateLimit-* 头并在超限时给 429 与 Retry-After；遵循内容协商，不支持时返回 406。服务端须白名单排序、过滤和展开字段，避免意外 ORDER BY 与 JOIN。列表端点从第一天就应分页，否则后续添加属破坏性变更。发布前检查表按 Blocker、Concern、Nit、Smell 分级。基准显示该技能可将状态码判断正确率从 40% 提升至 100%。