API Design

API and Interface Design

Overview

Stage: Spec · Plan — a referenced discipline, not a sequential stage. spec-grilling dispatches it in Spec to propose a variant for a load-bearing structural question; architecture-design dispatches it in Spec as a code-cold lens over a structure already written, grading the consumer surface that structure records; plan-breakdown reaches for it in Plan to pin the interface contract into plan.md; the Review fan-out applies it as a lens when a diff changes a surface a file outside the diff calls. It owns no artifact of its own. It is also invokable standalone for a pure interface refactor.

Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.

When to Use

• Designing new API endpoints
• Defining module boundaries or contracts between teams
• Creating component prop interfaces
• Establishing database schema that informs API shape
• Changing existing public interfaces

Inputs

Consumes:

• prd.md — sections ## Solution and ## Implementation Decisions: the product-altitude statement of what surfaces/endpoints/boundaries exist (product altitude only — prd.md carries no file paths or signatures; api-design is where those get pinned).
• research.md — the codebase/DB as-is, so new interfaces match existing conventions instead of forking a second style. What a proposed surface stands on is its ## Structural facts — seams and their adapter counts, module boundaries, conventions in use; _none_ where there are none.
• CONTEXT.md's ## Glossary (repo-root) — use its ubiquitous-language terms verbatim in names so the interface speaks the project's vocabulary.
• Existing docs/adr/ADR-<NNN>-*.md — prior interface decisions you MUST NOT contradict (e.g. a committed REST-vs-GraphQL or error-envelope choice).

Refuse-to-run condition: if there is nothing to design against — no research.md, no prd.md, no explicit standalone ask — STOP and ask for the missing input rather than invent a contract in a vacuum. A surface you propose from research.md and the intent is not a vacuum: in Spec the PRD does not exist yet, so those two are the whole substrate. For a standalone refactor, the existing code under change is the required input.

Core Principles

Hyrum's Law

With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.

This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:

• Be intentional about what you expose. Every observable behavior is a potential commitment.
• Don't leak implementation details. If users can observe it, they will depend on it.
• Plan for deprecation at design time. See deprecation-and-migration for how to safely remove things users depend on.
• Tests are not enough. Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.

The One-Version Rule

Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.

1. Contract First

Define the interface before implementing it. The contract is the spec — implementation follows.

// Define the contract first
interface TaskAPI {
  // Creates a task and returns the created task with server-generated fields
  createTask(input: CreateTaskInput): Promise<Task>;

  // Returns paginated tasks matching filters
  listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;

  // Returns a single task or throws NotFoundError
  getTask(id: string): Promise<Task>;

  // Partial update — only provided fields change
  updateTask(id: string, input: UpdateTaskInput): Promise<Task>;

  // Idempotent delete — succeeds even if already deleted
  deleteTask(id: string): Promise<void>;
}

2. Consistent Error Semantics

Pick one error strategy and use it everywhere:

// REST: HTTP status codes + structured error body
// Every error response follows the same shape
interface APIError {
  error: {
    code: string;        // Machine-readable: "VALIDATION_ERROR"
    message: string;     // Human-readable: "Email is required"
    details?: unknown;   // Additional context when helpful
  };
}

// Status code mapping
// 400 → Client sent invalid data
// 401 → Not authenticated
// 403 → Authenticated but not authorized
// 404 → Resource not found
// 409 → Conflict (duplicate, version mismatch)
// 422 → Validation failed (semantically invalid)
// 500 → Server error (never expose internal details)

Don't mix patterns. If some endpoints throw, others return null, and others return { error } — the consumer can't predict behavior.

3. Validate at Boundaries

Trust internal code. Validate at system edges where external input enters:

// Validate at the API boundary
app.post('/api/tasks', async (req, res) => {
  const result = CreateTaskSchema.safeParse(req.body);
  if (!result.success) {
    return res.status(422).json({
      error: {
        code: 'VALIDATION_ERROR',
        message: 'Invalid task data',
        details: result.error.flatten(),
      },
    });
  }

  // After validation, internal code trusts the types
  const task = await taskService.create(result.data);
  return res.status(201).json(task);
});

Where validation belongs:

• API route handlers (user input)
• Form submission handlers (user input)
• External service response parsing (third-party data -- always treat as untrusted)
• Environment variable loading (configuration)

Third-party API responses are untrusted data. Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.

Where validation does NOT belong:

• Between internal functions that share type contracts
• In utility functions called by already-validated code
• On data that just came from your own database

4. Prefer Addition Over Modification

Extend interfaces without breaking existing consumers:

// Good: Add optional fields
interface CreateTaskInput {
  title: string;
  description?: string;
  priority?: 'low' | 'medium' | 'high';  // Added later, optional
  labels?: string[];                       // Added later, optional
}

// Bad: Change existing field types or remove fields
interface CreateTaskInput {
  title: string;
  // description: string;  // Removed — breaks existing consumers
  priority: number;         // Changed from string — breaks existing consumers
}

5. Predictable Naming

REST API Patterns

Resource Design

GET    /api/tasks              → List tasks (with query params for filtering)
POST   /api/tasks              → Create a task
GET    /api/tasks/:id          → Get a single task
PATCH  /api/tasks/:id          → Update a task (partial)
DELETE /api/tasks/:id          → Delete a task

GET    /api/tasks/:id/comments → List comments for a task (sub-resource)
POST   /api/tasks/:id/comments → Add a comment to a task

Pagination

Paginate list endpoints:

// Request
GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc

// Response
{
  "data": [...],
  "pagination": {
    "page": 1,
    "pageSize": 20,
    "totalItems": 142,
    "totalPages": 8
  }
}

Filtering

Use query parameters for filters:

GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01

Partial Updates (PATCH)

Accept partial objects — only update what's provided:

// Only title changes, everything else preserved
PATCH /api/tasks/123
{ "title": "Updated title" }

TypeScript Interface Patterns

Use Discriminated Unions for Variants

// Good: Each variant is explicit
type TaskStatus =
  | { type: 'pending' }
  | { type: 'in_progress'; assignee: string; startedAt: Date }
  | { type: 'completed'; completedAt: Date; completedBy: string }
  | { type: 'cancelled'; reason: string; cancelledAt: Date };

// Consumer gets type narrowing
function getStatusLabel(status: TaskStatus): string {
  switch (status.type) {
    case 'pending': return 'Pending';
    case 'in_progress': return `In progress (${status.assignee})`;
    case 'completed': return `Done on ${status.completedAt}`;
    case 'cancelled': return `Cancelled: ${status.reason}`;
  }
}

Input/Output Separation

// Input: what the caller provides
interface CreateTaskInput {
  title: string;
  description?: string;
}

// Output: what the system returns (includes server-generated fields)
interface Task {
  id: string;
  title: string;
  description: string | null;
  createdAt: Date;
  updatedAt: Date;
  createdBy: string;
}

Use Branded Types for IDs

type TaskId = string & { readonly __brand: 'TaskId' };
type UserId = string & { readonly __brand: 'UserId' };

// Prevents accidentally passing a UserId where a TaskId is expected
function getTask(id: TaskId): Promise<Task> { ... }

Common Rationalizations

Red Flags

• Endpoints that return different shapes depending on conditions
• Inconsistent error formats across endpoints
• Validation scattered throughout internal code instead of at boundaries
• Breaking changes to existing fields (type changes, removals)
• List endpoints without pagination
• Verbs in REST URLs (/api/createTask, /api/getUsers)
• Third-party API responses used without validation or sanitization

Verification

After designing an API:

• Every endpoint has typed input and output schemas
• Error responses follow a single consistent format
• Validation happens at system boundaries only
• List endpoints support pagination
• New fields are additive and optional (backward compatible)
• Naming follows consistent conventions across all endpoints
• API documentation or types are committed alongside the implementation

Outputs & handoff contract

Emits: the interface contract written into plan.md — typed input/output schemas, the single error envelope, resource/endpoint shapes, discriminated unions, and branded IDs — placed where the slices that build to them can read the exact signatures cold. api-design owns no standalone artifact file; plan-breakdown owns plan.md and the slice DAG.

ADR escalation: any hard-to-reverse interface decision — REST vs GraphQL vs tRPC, the shape of a public API surface, a versioning strategy, the product-wide error-envelope standard — is written as an ADR at docs/adr/ADR-<NNN>-*.md using the documentation-and-adrs standard and referenced by id from plan.md. Reversible interface detail stays inline in plan.md. This is the single load-bearing dependency on documentation-and-adrs.

Stable sections consumers read cold (the contract block in plan.md):

• incremental-implementation builds to the exact typed signatures and the single error envelope.
• test-driven-development realizes the contract's observable behavior as tests (asserting outcomes, not internals).
• pull-request anchors its design summary to the interface decisions (and any ADR ids) when the slice ships.

STATE.md update: none directly. api-design runs inside the human-owned Spec and Plan stages as a referenced discipline; plan-breakdown seeds the feature's slice rows + DAG into STATE.md. api-design only contributes contract content into plan.md (and, when warranted, one ADR).

Change-the-shape rule: if a published interface contract later changes shape, update its consumers (incremental-implementation + test-driven-development + the pull-request design anchor) in the same commit. If the decision was promoted to an ADR, supersede the ADR via a link and update its referrers in the same commit — never delete it (ADR cross-ref rule). This is the artifact-level expression of the skill's own "Prefer Addition Over Modification" principle.