What problem does it solve? Designing a REST API involves dozens of interlocking decisions — resource naming, HTTP methods, status codes, error formats, pagination, versioning, auth, and rate limiting — and inconsistent choices produce APIs that are hard to consume and evolve. This Skill applies opinionated, standards-based defaults (RFC 9110, RFC 9457, OpenAPI 3.1) so every design decision is coherent and the result maps directly onto a machine-readable contract. ## Core Features & Use Cases - Resource and method modeling: Turns domain nouns into plural, consistently nested URL resources and assigns the correct HTTP method with idempotency semantics (PUT vs PATCH, Idempotency-Key for retried POSTs). - Status codes and one error model: Picks the right status per outcome (400 vs 422, 401 vs 403, 409) and standardizes all errors on RFC 9457 application/problem+json with an errors array for field-level validation. - Contract patterns: Defines a single success/pagination envelope (cursor/keyset by default, offset for small stable datasets), URL-path major versioning with Deprecation/Sunset headers, Bearer/API-key auth, and 429 + Retry-After rate limiting. - OpenAPI 3.1 output: Maps the finished design onto a complete OpenAPI 3.1 document with $ref-reused schemas, responses, parameters, and security schemes. - Use Case: Given domain entities like orders and customers, produce the full endpoint map, status-code table, problem+json error model, cursor-paginated list envelope, and a worked OpenAPI 3.1 contract ready for a FastAPI engineer to implement. ## Quick Start Use rest-api-design to design the REST API for my orders and customers domain and produce the OpenAPI 3.1 contract.