API Design Principles 是一个围绕 API 设计原则的技能，目标是用 REST 与 GraphQL 的设计方法构建直观、可扩展、可维护的 API。资料将其定位为在设计新 API、重构既有 API、为团队建立 API 设计标准、实现前评审 API 规格、在 API 范式之间迁移（如 REST 到 GraphQL）、编写面向开发者的 API 文档，以及针对移动端或第三方集成等场景优化 API 时使用。
REST 部分强调面向资源的架构：资源使用名词（users、orders、products）而非动词，动作交给 HTTP 方法（GET、POST、PUT、PATCH、DELETE），URL 表达资源层级，命名保持一致。HTTP 方法语义为：GET 获取资源（幂等、安全）；POST 创建新资源；PUT 整体替换资源（幂等）；PATCH 部分更新；DELETE 删除资源（幂等）。
GraphQL 部分强调 Schema 优先开发：用类型定义领域模型，查询用于读取，变更用于修改，订阅用于实时更新。查询结构上，客户端精确请求所需数据，单一端点承载多种操作，Schema 强类型，内置内省。
版本控制策略给出三种常见方式：URL 版本（如 /api/v1/users）、Header 版本（如 Accept: application/vnd.api+json; version=1）和查询参数版本（如 /api/users?version=1）。
REST 设计模式包括：资源集合设计（给出面向资源的端点示例与应避免的动作型端点示例）、分页与过滤（FastAPI 示例，包含 PaginatedResponse 模型及 page、page_size、status、search 查询参数与响应计算）、错误处理与状态码（状态码字典与 404 抛出示例）、HATEOAS（在用户响应中嵌入 _links，包含 self、orders、update、delete 等链接）。
GraphQL 设计模式包括：Schema 设计（User、OrderConnection、PageInfo、Mutation、CreateUserInput、CreateUserPayload 等类型定义，含基于游标的分页结构），以及 DataLoader 防 N+1（通过 batch_load_fn 批量加载用户）。
最佳实践方面，REST 建议：集合名用复数、保持无状态、正确使用 HTTP 状态码（2xx 成功、4xx 客户端错误、5xx 服务端错误）、为 API 做版本规划、大集合必须分页、设置速率限制、使用 OpenAPI/Swagger 提供交互式文档。GraphQL 建议：Schema 优先、用 DataLoader 避免 N+1、在 Schema 与解析器层做输入校验、在变更载荷中返回结构化错误、使用游标分页（Relay 规范）、用 @deprecated 指令渐进迁移、监控查询复杂度与执行时间。
常见陷阱包括：REST 的过度获取与获取不足（GraphQL 可缓解但需 DataLoader）、破坏性变更、错误格式不一致、缺少速率限制、文档缺失、忽视 HTTP 语义（例如对幂等操作使用 POST）、API 结构与数据库 Schema 过度耦合。
资料未说明该技能的具体安装方式、运行环境、平台支持、收费模式或价格信息。