api-design

Provides REST API design conventions covering resource naming, status codes, pagination, filtering, and versioning.

Updated Apr 18, 2026
One-click install
npx skills add https://github.com/JohnRebellion/.claude-public --skill api-design-johnrebellion
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-design
Source: https://github.com/JohnRebellion/.claude-public/tree/main/claude/skills/api-design
Command: npx skills add https://github.com/JohnRebellion/.claude-public --skill api-design-johnrebellion

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing consistent REST APIs is hard: teams often return 200 for every response, mix verbs into URLs, skip pagination, and invent ad-hoc error formats. This Skill supplies a complete set of conventions and implementation patterns so endpoints are predictable, secure, and developer-friendly. ## Core Features & Use Cases - Resource and URL Conventions: Enforces plural, kebab-case, noun-based URLs with correct HTTP method semantics and status codes (201 with Location, 422 for validation, 429 for rate limits). - Pagination, Filtering, and Sorting: Provides offset and cursor pagination patterns with guidance on when to use each, plus query parameter conventions for filtering, sorting, search, and sparse fieldsets. - Standard Response Formats: Defines success, collection, and error response envelopes with field-level validation details, plus rate limiting headers and versioning strategy. - Implementation Examples: Includes ready-to-adapt code for TypeScript (Next.js with Zod), Python (Django REST Framework), and Go (net/http), plus a pre-ship design checklist. - Use Case: When adding a new endpoint to a production API, activate this Skill to validate the URL structure, choose the right status codes, and generate a compliant error response format before writing code. ## Quick Start Review my new POST /api/v1/orders endpoint and check it against REST API design best practices for status codes, validation, and error responses.

Frequently Asked Questions about api-design

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

FAQPage Schema
How do I design REST API endpoints with correct naming conventions?▼

Use plural, lowercase, kebab-case nouns for resources like /api/v1/team-members, and nest sub-resources for ownership such as /users/:id/orders. Avoid verbs in URLs; reserve them only for non-CRUD actions like /orders/:id/cancel.

What HTTP status codes should a REST API return?▼

Return 200 for successful reads, 201 with a Location header for creations, 204 for deletes, 400 or 422 for validation failures, 404 for missing resources, 409 for conflicts, and 429 for rate limiting. Never return 200 with an error payload in the body.

Should I use cursor or offset pagination for my API?▼

Use offset pagination for admin dashboards and small datasets where users jump to page numbers. Use cursor pagination for infinite scroll, feeds, and large datasets because it performs consistently and stays stable with concurrent inserts.

How do I format REST API error responses?▼

Return a structured error object with a machine-readable code, a human-readable message, and a details array containing field-level validation errors. Pair this with the correct HTTP status code such as 422 for semantic validation failures.

When should I version my REST API?▼

Start with /api/v1/ and only create a new version for breaking changes like removing fields, changing types, or altering authentication. Adding fields, optional parameters, or new endpoints is non-breaking and needs no new version.

What are the limitations of offset-based pagination?▼

Offset pagination degrades on large offsets because the database must scan skipped rows, and results shift when records are inserted concurrently. For large or frequently changing datasets, cursor-based pagination avoids both problems.