engineering
API Design Guide
Design RESTful and GraphQL APIs with consistent naming conventions, versioning strategy, pagination patterns, error response formats, authentication schemes, and rate limiting — producing a complete API specification.
api-designRESTGraphQLendpointsversioningdocumentation
Works well with agents
$ npx skills add The-AI-Directory-Company/(…) --skill api-design-guideapi-design-guide/
SKILL.md
Markdown
| 1 | |
| 2 | # API Design Guide |
| 3 | |
| 4 | ## Before you start |
| 5 | |
| 6 | Gather the following from the user: |
| 7 | |
| 8 | 1. **What resources does the API expose?** (Users, orders, products, etc.) |
| 9 | 2. **Who are the consumers?** (Internal services, third-party developers, mobile apps, SPAs) |
| 10 | 3. **REST, GraphQL, or both?** Default to REST for CRUD-heavy services, GraphQL for query-heavy frontends. |
| 11 | 4. **Auth requirements?** (API keys, OAuth 2.0, JWT, session-based) |
| 12 | 5. **Expected traffic volume?** (Drives rate limiting and pagination decisions) |
| 13 | 6. **Versioning constraints?** (Breaking changes expected? Public vs. internal?) |
| 14 | |
| 15 | If the user says "design an API for X" without specifics, push back: "What operations do consumers need to perform? What data do they send and receive?" |
| 16 | |
| 17 | ## API design template |
| 18 | |
| 19 | ### 1. Resource Naming |
| 20 | |
| 21 | Use plural nouns for collections. Resources are things, not actions. |
| 22 | |
| 23 | **Good**: `/users`, `/orders`, `/order-items` |
| 24 | **Bad**: `/getUsers`, `/createOrder`, `/user_list`, `/OrderItem` |
| 25 | |
| 26 | - Lowercase with hyphens for multi-word resources (`/order-items`, not `/orderItems`) |
| 27 | - Nouns only — never verbs in the URL path |
| 28 | - Nest to express ownership: `/users/{id}/orders` — limit nesting to two levels |
| 29 | |
| 30 | ### 2. HTTP Methods |
| 31 | |
| 32 | | Method | Purpose | Idempotent | Success Code | |
| 33 | |--------|---------|------------|--------------| |
| 34 | | GET | Read resource(s) | Yes | 200 | |
| 35 | | POST | Create resource | No | 201 | |
| 36 | | PUT | Full replace | Yes | 200 | |
| 37 | | PATCH | Partial update | No | 200 | |
| 38 | | DELETE | Remove resource | Yes | 204 | |
| 39 | |
| 40 | Use POST for actions that don't map to CRUD: `POST /orders/{id}/cancel`. |
| 41 | |
| 42 | ### 3. Request/Response Formats |
| 43 | |
| 44 | Always use JSON. Wrap collection responses — never return a bare array: |
| 45 | |
| 46 | ```json |
| 47 | { |
| 48 | "data": [{ "id": "usr_01", "name": "Alice" }], |
| 49 | "meta": { "total": 142, "page": 1, "per_page": 20 } |
| 50 | } |
| 51 | ``` |
| 52 | |
| 53 | ### 4. Error Handling |
| 54 | |
| 55 | Return a consistent error envelope on every failure: |
| 56 | |
| 57 | ```json |
| 58 | { |
| 59 | "error": { |
| 60 | "code": "VALIDATION_ERROR", |
| 61 | "message": "Email address is invalid.", |
| 62 | "details": [{ "field": "email", "reason": "Must be a valid email address." }], |
| 63 | "request_id": "req_abc123" |
| 64 | } |
| 65 | } |
| 66 | ``` |
| 67 | |
| 68 | Status code mapping: 400 (validation), 401 (unauthenticated), 403 (unauthorized), 404 (not found), 409 (conflict), 422 (semantically invalid), 429 (rate limited), 500 (server error — never expose internals). |
| 69 | |
| 70 | ### 5. Pagination |
| 71 | |
| 72 | Use cursor-based pagination for large or real-time datasets, offset-based for simple UIs. Always include pagination metadata and a `next` link. Default `per_page` to 20, cap at 100. |
| 73 | |
| 74 | - **Cursor**: `GET /orders?cursor=eyJpZCI6MTAwfQ&limit=20` |
| 75 | - **Offset**: `GET /orders?page=2&per_page=20` |
| 76 | |
| 77 | ### 6. Versioning |
| 78 | |
| 79 | Use URL-prefix versioning (`/v1/`) for public APIs. Use header versioning only for per-endpoint granularity. Increment the major version only for breaking changes. Never remove or rename a field within the same version. Support at least N-1 versions with a published deprecation timeline. |
| 80 | |
| 81 | ### 7. Authentication |
| 82 | |
| 83 | | Scheme | Best for | |
| 84 | |--------|----------| |
| 85 | | API keys | Server-to-server, internal services | |
| 86 | | OAuth 2.0 + PKCE | Third-party integrations, user-facing apps | |
| 87 | | JWT (short-lived) | Stateless auth between microservices | |
| 88 | | Session cookies | Traditional web apps with same-origin frontend | |
| 89 | |
| 90 | Always use HTTPS. Never accept auth tokens in query strings — use the `Authorization` header. |
| 91 | |
| 92 | ### 8. Rate Limiting |
| 93 | |
| 94 | Return rate limit headers (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`). Define tiers by consumer type (free, paid, internal). Return `429` with `Retry-After` when the limit is hit. |
| 95 | |
| 96 | ## Good vs. bad API design |
| 97 | |
| 98 | | Aspect | Bad | Good | |
| 99 | |--------|-----|------| |
| 100 | | URL | `GET /api/getUsersByStatus?s=active` | `GET /v1/users?status=active` | |
| 101 | | Error | `{ "success": false, "msg": "bad" }` | `{ "error": { "code": "VALIDATION_ERROR", "message": "..." } }` | |
| 102 | | Pagination | Returning 10,000 records with no limit | Cursor pagination with default limit of 20 | |
| 103 | | Versioning | Changing field names without a new version | Adding fields to existing version, removing via new version | |
| 104 | | Auth | API key in the URL (`?key=abc`) | `Authorization: Bearer <token>` header | |
| 105 | |
| 106 | ## Quality checklist |
| 107 | |
| 108 | Before delivering the API specification, verify: |
| 109 | |
| 110 | - [ ] Every resource uses plural nouns, lowercase, hyphen-separated |
| 111 | - [ ] HTTP methods match their semantic purpose (GET reads, POST creates) |
| 112 | - [ ] All endpoints document request body, query params, and response shape |
| 113 | - [ ] Error responses follow a single consistent envelope format |
| 114 | - [ ] Pagination is implemented for every collection endpoint |
| 115 | - [ ] Versioning strategy is documented with a deprecation policy |
| 116 | - [ ] Auth scheme is specified for every endpoint (public endpoints explicitly marked) |
| 117 | - [ ] Rate limits are defined per consumer tier with documented headers |
| 118 | - [ ] No endpoint returns unbounded data — every list has a max page size |
| 119 | - [ ] Breaking vs. non-breaking changes are clearly defined |
| 120 |