api-patterns
API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
Works with
--- name: api-patterns description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination. license: MIT --- # API Patterns > API design principles and decision-making for 2025. > **Learn to THINK, not copy fixed patterns.** ## 🎯 Selective Reading Rule **Read ONLY files relevant to the request!** Check the content map, find what you need. --- ## 📑 Content Map | File | Description | When to Read | |------|-------------|--------------| | `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type | | `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API | | `response.md` | Envelope pattern, error format, pagination | Response structure | | `graphql.md` | Schema design, when to use, security | Considering GraphQL | | `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects | | `versioning.md` | URI/Header/Query versioning | API evolution planning | | `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection | | `rate-limiting.md` | Token bucket, sliding window | API protection | | `documentation.md` | OpenAPI/Swagger best practices | Documentation | | `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits | --- ## 🔗 Related Skills | Need | Skill | |------|-------| | API implementation | `@[skills/backend-development]` | | Data structure | `@[skills/database-design]` | | Security details | `@[skills/security-hardening]` | --- ## ✅ Decision Checklist Before designing an API: - [ ] **Asked user about API consumers?** - [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC) - [ ] **Defined consistent response format?** - [ ] **Planned versioning strategy?** - [ ] **Considered authentication needs?** - [ ] **Planned rate limiting?** - [ ] **Documentation approach defined?** --- ## ❌ Anti-Patterns **DON'T:** - Default to REST for everything - Use verbs in REST endpoints (/getUsers) - Return inconsistent response formats - Expose internal errors to clients - Skip rate limiting **DO:** - Choose API style based on context - Ask about client requirements - Document thoroughly - Use appropriate status codes --- ## Script | Script | Purpose | Command | |--------|---------|---------| | `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` | ## When to Use This skill is applicable to execute the workflow or actions described in the overview. ## Limitations - Use this skill only when the task clearly matches the scope described above. - Do not treat the output as a substitute for environment-specific validation, testing, or expert review. - Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
More API Design skills
lark-event
larksuite/cli
Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting started/joined/ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.
lark-contact
larksuite/cli
飞书 / Lark 通讯录:按姓名 / 邮箱解析成 open_id,或按 open_id 反查姓名 / 部门 / 邮箱 / 联系方式 / 个人状态 / 签名,以及按关键词搜索当前用户可见的机器人 / 智能体(agent)。当用户提到一个名字要下一步发消息 / 排日程,或拿到 open_id 想查具体信息时使用。不负责部门树遍历、按部门列员工、组织架构图,这类需求走原生 OpenAPI。
lark-openapi-explorer
larksuite/cli
飞书/Lark 原生 OpenAPI 探索:从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足,需要查找并调用原生飞书 OpenAPI 时使用。

