home / skills / phrazzld / claude-config / api-design

api-design skill

/skills/api-design

This skill helps design robust REST APIs with OpenAPI, versioning, and consistent error handling to streamline endpoints, docs, and client integration.

npx playbooks add skill phrazzld/claude-config --skill api-design

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.7 KB
---
name: api-design
description: |
  REST API design principles, versioning, and documentation. Use when:
  - Designing new API endpoints
  - Choosing between REST, GraphQL, or gRPC
  - Implementing API versioning
  - Writing OpenAPI specifications
  - Handling API errors
  Keywords: REST, API, OpenAPI, Swagger, versioning, HTTP methods,
  status codes, pagination, error handling
effort: high
---

# API Design

REST-first, OpenAPI-driven, backward-compatible by default.

## REST Principles

**Resources as nouns. HTTP methods as verbs:**
```
GET    /users          # List users
GET    /users/123      # Get user
POST   /users          # Create user
PUT    /users/123      # Replace user
PATCH  /users/123      # Update user
DELETE /users/123      # Delete user

# Relationships through URL hierarchy
GET /users/123/orders
```

**Never:** `/getUser`, `/createOrder`, `/api/processPayment`

## HTTP Status Codes

| Code | When |
|------|------|
| 200 | Successful GET, PUT, PATCH |
| 201 | Successful POST (created) |
| 204 | Successful DELETE (no body) |
| 400 | Invalid request format |
| 401 | Not authenticated |
| 403 | Not authorized |
| 404 | Resource not found |
| 409 | Business logic conflict |
| 422 | Validation failed |
| 500 | Server error |

## Error Format

```json
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Invalid request data",
    "details": [
      {
        "field": "email",
        "message": "Invalid email format",
        "value": "not-an-email"
      }
    ]
  }
}
```

## Pagination

```
GET /users?page=2&per_page=50&sort=created_at&order=desc

{
  "data": [...],
  "meta": {
    "page": 2,
    "per_page": 50,
    "total": 150,
    "total_pages": 3
  }
}
```

## Versioning

**URL versioning for public APIs:**
```
/v1/users
/v2/users
```

**Rules:**
- Major version for breaking changes only
- 6-month deprecation notice minimum
- Side-by-side version support during transition
- Additive changes don't require new version

## OpenAPI First

**Write spec before code:**
```yaml
openapi: 3.0.0
paths:
  /users/{id}:
    get:
      summary: Get user by ID
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        '200':
          description: User found
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/User'
        '404':
          description: User not found
```

## Anti-Patterns

- RPC-style endpoints (`/api/getUserById`)
- POST for everything
- Deep nesting (`/users/123/orders/456/items/789`)
- Inconsistent error formats
- Breaking changes without version bump
- Documentation that doesn't match implementation

Overview

This skill provides pragmatic REST API design guidance focused on REST-first, OpenAPI-driven development and backward compatibility. It covers resource modeling, HTTP status usage, error formats, pagination, versioning rules, and anti-patterns. Use it to produce consistent, well-documented APIs that are easy to evolve and consume.

How this skill works

The skill inspects API surface and design choices and recommends patterns: noun-based resources, correct HTTP methods and status codes, consistent error payloads, and pagination schemas. It guides versioning strategy (URL versioning for public APIs, deprecation timelines) and enforces OpenAPI-first workflows by showing spec examples to drive implementation and documentation.

When to use it

  • Designing new REST endpoints or reworking resource models
  • Choosing between REST, GraphQL, or gRPC for a use case
  • Implementing API versioning and deprecation policies
  • Writing or validating OpenAPI/Swagger specifications before coding
  • Defining consistent error formats, paging, and status code semantics

Best practices

  • Model resources as nouns and use HTTP methods for actions (GET/POST/PUT/PATCH/DELETE)
  • Return appropriate status codes (201 for created, 204 for deletes, 4xx for client errors)
  • Publish an OpenAPI spec first and keep it as the source of truth
  • Use URL versioning for public APIs, bump major versions only for breaking changes
  • Provide consistent error objects with code, message, and details for validation errors

Example use cases

  • Designing a user and orders API with list, retrieve, create, update, and delete endpoints
  • Converting ad-hoc RPC-style endpoints into resource-oriented REST paths
  • Preparing an OpenAPI document to generate client SDKs and server stubs
  • Defining pagination and sorting for large list endpoints with meta and total counts
  • Planning a v1→v2 rollout with side-by-side support and a 6-month deprecation notice

FAQ

When should I version an API?

Create a new major version only for breaking changes. Additive, backward-compatible changes do not require a version bump.

Which status code for validation errors?

Use 422 for validation failure with an error object detailing field-level issues; use 400 for malformed requests.