awesome-api-designlisted

# API Design Shape an HTTP API so its consumers can build against it for years without a breaking surprise. The contract is the product: URLs, methods, payloads, errors, and evolution rules are decided here, deliberately — everything left implicit becomes an accidental contract the first client depends on. ## When to Activate - "Design the API for X", "review this API design / OpenAPI spec", "how should we version / paginate / handle retries". - A design doc needs its API section made concrete (awesome-design-doc hands off here). - A new endpoint is being added to an existing API and must match its conventions. Do not activate to define the error envelope's fields or retry classification (awesome-error-standards owns that contract) or to audit implemented handlers for vulnerabilities (awesome-security-audit). ## Work Process 1. Inventory the incumbent conventions and the project's own words — an existing API's casing, id format, pagination style, and envelope win over any guideline here: consistency within one API beats global best practice. Only a new API starts from the defaults below. Read the recorded decisions (existing ADRs) and the project's glossary (`CONTEXT.md`, a domain doc, or the terms its code and tests already use) before naming a single resource: a path is a public, long-lived name, and one that renames a concept the codebase already has costs every reader a translation. 2. Model resources, not procedures — nouns with identity and lifecycle (`/orders/{id