$npx -y skills add SamarthaKV29/antigravity-god-mode --skill api-patternsAPI design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.
| 1 | # API Patterns |
| 2 | |
| 3 | > API design principles and decision-making for 2025. |
| 4 | > **Learn to THINK, not copy fixed patterns.** |
| 5 | |
| 6 | ## 🎯 Selective Reading Rule |
| 7 | |
| 8 | **Read ONLY files relevant to the request!** Check the content map, find what you need. |
| 9 | |
| 10 | --- |
| 11 | |
| 12 | ## 📑 Content Map |
| 13 | |
| 14 | | File | Description | When to Read | |
| 15 | |------|-------------|--------------| |
| 16 | | `api-style.md` | REST vs GraphQL vs tRPC decision tree | Choosing API type | |
| 17 | | `rest.md` | Resource naming, HTTP methods, status codes | Designing REST API | |
| 18 | | `response.md` | Envelope pattern, error format, pagination | Response structure | |
| 19 | | `graphql.md` | Schema design, when to use, security | Considering GraphQL | |
| 20 | | `trpc.md` | TypeScript monorepo, type safety | TS fullstack projects | |
| 21 | | `versioning.md` | URI/Header/Query versioning | API evolution planning | |
| 22 | | `auth.md` | JWT, OAuth, Passkey, API Keys | Auth pattern selection | |
| 23 | | `rate-limiting.md` | Token bucket, sliding window | API protection | |
| 24 | | `documentation.md` | OpenAPI/Swagger best practices | Documentation | |
| 25 | | `security-testing.md` | OWASP API Top 10, auth/authz testing | Security audits | |
| 26 | |
| 27 | --- |
| 28 | |
| 29 | ## 🔗 Related Skills |
| 30 | |
| 31 | | Need | Skill | |
| 32 | |------|-------| |
| 33 | | API implementation | `@[skills/backend-development]` | |
| 34 | | Data structure | `@[skills/database-design]` | |
| 35 | | Security details | `@[skills/security-hardening]` | |
| 36 | |
| 37 | --- |
| 38 | |
| 39 | ## ✅ Decision Checklist |
| 40 | |
| 41 | Before designing an API: |
| 42 | |
| 43 | - [ ] **Asked user about API consumers?** |
| 44 | - [ ] **Chosen API style for THIS context?** (REST/GraphQL/tRPC) |
| 45 | - [ ] **Defined consistent response format?** |
| 46 | - [ ] **Planned versioning strategy?** |
| 47 | - [ ] **Considered authentication needs?** |
| 48 | - [ ] **Planned rate limiting?** |
| 49 | - [ ] **Documentation approach defined?** |
| 50 | |
| 51 | --- |
| 52 | |
| 53 | ## ❌ Anti-Patterns |
| 54 | |
| 55 | **DON'T:** |
| 56 | - Default to REST for everything |
| 57 | - Use verbs in REST endpoints (/getUsers) |
| 58 | - Return inconsistent response formats |
| 59 | - Expose internal errors to clients |
| 60 | - Skip rate limiting |
| 61 | |
| 62 | **DO:** |
| 63 | - Choose API style based on context |
| 64 | - Ask about client requirements |
| 65 | - Document thoroughly |
| 66 | - Use appropriate status codes |
| 67 | |
| 68 | --- |
| 69 | |
| 70 | ## Script |
| 71 | |
| 72 | | Script | Purpose | Command | |
| 73 | |--------|---------|---------| |
| 74 | | `scripts/api_validator.py` | API endpoint validation | `python scripts/api_validator.py <project_path>` | |