4e8e5069fa
- Added: api-patterns, app-builder, architecture, bash-linux, behavioral-modes, clean-code, code-review-checklist, database-design, deployment-procedures, docker-expert, documentation-templates, game-development, geo-fundamentals, i18n-localization, lint-and-validate, mobile-design, nestjs-expert, nextjs-best-practices, nodejs-best-practices, parallel-agents, performance-profiling, plan-writing, powershell-windows, prisma-expert, python-patterns, react-patterns, red-team-tactics, seo-fundamentals, server-management, tailwind-patterns, tdd-workflow, typescript-expert, vulnerability-scanner - Updated README: skill count 179 → 223 - Added credit for vudovn/antigravity-kit (MIT License) Source: https://github.com/vudovn/antigravity-kit
82 lines
2.4 KiB
Markdown
82 lines
2.4 KiB
Markdown
---
|
|
name: api-patterns
|
|
description: API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
|
|
allowed-tools: Read, Write, Edit, Glob, Grep
|
|
---
|
|
|
|
# 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>` |
|
|
|