API Design taste

# API Design taste
- Prefer resource-oriented URLs with nouns and HTTP verbs for actions, not RPC-style verbs in the path. Confidence: 0.95
- Version APIs in the URL path (`/v1/...`) and keep breaking changes out of an existing major version. Confidence: 0.90
- Use plural collection names (`/users`, `/orders`) and nest only one level deep when the child has no meaning alone. Confidence: 0.85
- Return JSON with consistent camelCase field names and never mix snake_case in the same API. Confidence: 0.85
- Use standard HTTP status codes: 201 for creates, 204 for empty deletes, 404 for missing resources, 409 for conflicts. Confidence: 0.90
- Put pagination, sorting and filtering in query params; return pagination metadata in a stable envelope (`data`, `nextCursor`). Confidence: 0.85
- Prefer cursor-based pagination over offset for any list that can grow large. Confidence: 0.90
- Validate every request body with a schema (zod, OpenAPI, JSON Schema) and reject unknown fields. Confidence: 0.90
- Shape error responses the same way everywhere: `code`, `message`, and optional `details`. Confidence: 0.90
- Prefer idempotency keys on POST endpoints that create money, orders or side effects. Confidence: 0.85
- Use ETags or `If-Match` for concurrent updates on contested resources. Confidence: 0.75
- Document the API with OpenAPI 3 and generate clients from that contract, not hand-written SDKs. Confidence: 0.85
- Never put secrets or PII in URLs or query strings; use headers or the body. Confidence: 0.95
- Prefer explicit expansion (`?include=`) over always embedding related entities. Confidence: 0.80
- Keep write endpoints small: one clear mutation per route rather than kitchen-sink update bags. Confidence: 0.80
- Rate-limit by API key or user and return `Retry-After` when limited. Confidence: 0.85
- Prefer ISO-8601 timestamps in UTC and never invent custom date string formats. Confidence: 0.95