API Pattern Decision Guide

Problem

Many API projects default to REST or copy resource naming without checking who consumes the API. That often produces inconsistent response shapes, missing versioning, late security decisions, and unclear rate-limiting behavior. This skill treats API design as a scenario decision problem: confirm the client first, choose between REST, GraphQL, and tRPC, then define response structure, versioning, auth, rate limiting, documentation, and security testing.

How It Works

It does not push one fixed style guide. Instead, it provides a content map so readers can pull the relevant file for the task. Key areas include:
- api-style.md: decision guidance for REST, GraphQL, and tRPC.
- rest.md: resource naming, HTTP methods, and status codes.
- response.md: envelope patterns, error formats, and pagination.
- auth.md and rate-limiting.md: JWT, OAuth, Passkeys, API keys, token buckets, and sliding windows.
- security-testing.md: checks aligned with OWASP API Top 10, including authentication and authorization tests.
In practice, the workflow is checklist-driven: confirm API consumers, select a style, standardize responses, plan versioning, define auth, add rate limits, and write documentation. It also flags anti-patterns such as /getUsers, inconsistent responses, exposed internal errors, and missing rate limiting, and references scripts/api_validator.py for endpoint validation.

Boundaries

This is useful before API design, review, or migration, especially for TypeScript full-stack projects, internal APIs, and public platforms. It is not a backend framework and does not replace database design, security hardening, or organization-specific standards. If your team already has mandatory standards, use them as the source of truth and treat this skill as a decision rationale and checklist.