api-design

Designs REST API contracts, resource models, pagination schemes, and OpenAPI 3.1 specifications.

22|Updated Sep 10, 2026
One-click install
npx skills add https://github.com/Lynricsy/HyperSkills --skill api-design-lynricsy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-design
Source: https://github.com/Lynricsy/HyperSkills/tree/main/skills/api-design
Command: npx skills add https://github.com/Lynricsy/HyperSkills --skill api-design-lynricsy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? HTTP APIs often ship with inconsistent contracts: verbs in URIs, failures hidden under 200 status codes, offset pagination that duplicates or skips rows, and breaking changes rolled out without deprecation. This Skill provides a complete rule set and gated workflows for designing, reviewing, and evolving REST API contracts so the wire surface stays consistent and compatible. ## Core Features & Use Cases - Contract design workflow: Model resources from client-facing nouns, assign methods and status codes by HTTP semantics, design collections with cursor or keyset pagination, and define an RFC 9457 problem-details error contract. - Contract review and evolution: Audit an existing endpoint list or OpenAPI document against 25 core rules, classify proposed changes on wire, source, and semantic compatibility axes, and plan deprecation with Deprecation and Sunset headers. - Executable validation gates: Every design ends with redocly lint exiting clean and a prism mock server exercising the happy path, pagination, validation failures, and auth failures. - Use Case: Given a legacy endpoint list with /getWarehouse and /createOrder style paths, produce a redesigned contract with noun-based resources, correct status codes, an idempotency strategy for retried writes, and a validated OpenAPI 3.1 document. ## Quick Start Ask the agent to redesign your service's endpoint list as a proper REST contract with resources, methods, status codes, pagination, and an OpenAPI document validated by redocly lint and prism mock.

Frequently Asked Questions about api-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a REST API contract with proper pagination?

Paginate every collection from its first release, defaulting to an opaque cursor over keyset pagination with a unique tiebreaker like (created_at, id) in both the sort and the cursor. Keep offset only for screens needing numbered pages, document a default and maximum page size, and make total counts opt-in.

How do I review an OpenAPI document for contract mistakes?

Read the document end to end, list the implied resources, then check each operation against rules for verbs in paths, method semantics, 2xx failures, missing Location headers, and undeclared error responses. Finish by running redocly lint and exercising a prism mock, since lint misses issues like unpaginated collections and bare array responses.

What is the difference between RFC 9457 and RFC 7807 problem details?

RFC 9457 obsoletes RFC 7807 with the format unchanged in substance, but adds the problem type registry and about:blank guidance. New contracts should cite 9457, use application/problem+json, and let clients identify problems by the stable type URI rather than human-readable title or detail strings.

Which API changes are breaking versus compatible?

Judge changes on three axes: wire, source, and semantic compatibility. Adding a required request field, renaming or retyping a field, adding pagination to an existing collection, and changing defaults or units are all breaking; adding optional fields, new endpoints, and new request enum values are compatible.

When should an API operation be asynchronous with 202?

Make an operation asynchronous when its p99 duration exceeds about a second or the client should poll before proceeding. Return 202 with an Operation-Location header pointing at a status-monitor resource plus Retry-After, and never model PATCH as a long-running operation.

Does this skill cover API implementation in FastAPI or Spring?

No, it covers only the wire contract: resources, URIs, methods, status codes, pagination, errors, and the OpenAPI document. Implementation concerns like routers, handlers, validation wiring, and ORM access belong to framework-specific skills such as fastapi, nodejs-backend, java-spring, or csharp-dotnet.