api-and-interface-design

Guides design of stable REST APIs, TypeScript interfaces, and module contracts.

1|Updated Mar 2, 2025
One-click install
npx skills add https://github.com/marjorg/setup --skill api-and-interface-design-marjorg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/marjorg/setup/tree/main/home/.agents/skills/api-and-interface-design
Command: npx skills add https://github.com/marjorg/setup --skill api-and-interface-design-marjorg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Poorly designed interfaces create breaking changes, inconsistent error handling, and hidden dependencies that break consumers. This Skill provides concrete principles and patterns for designing APIs and module boundaries that remain stable as systems evolve. ## Core Features & Use Cases - Contract-First Design: Define typed interfaces before implementation, with consistent error semantics, boundary validation, and predictable naming conventions. - Idempotency Implementation: Detailed guidance on honouring idempotency keys, including atomic key claiming, payload guards, in-flight duplicate handling, and retention policies. - REST and TypeScript Patterns: Covers resource design, pagination, filtering, PATCH semantics, discriminated unions, input/output separation, and branded ID types. - Use Case: When designing a new tasks API, apply this Skill to define the endpoint contracts, error response shape, pagination scheme, and idempotency strategy before writing any implementation code. ## Quick Start Ask the AI to design a REST API for a new resource following the api-and-interface-design principles, including typed contracts and error handling.

Frequently Asked Questions about api-and-interface-design

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

FAQPage Schema
How do I design a REST API that won't break existing consumers?

Define the contract first with typed input and output schemas, then extend interfaces only by adding optional fields. Never change existing field types or remove fields, and follow consistent naming conventions like plural nouns for endpoints and camelCase for fields.

How to implement idempotency keys for API endpoints?

Accept an Idempotency-Key header from the client and claim it atomically using a database unique constraint, not a check-then-insert. Guard against key reuse with a different payload by comparing request hashes, and set key retention longer than the longest possible retry path.

Where should input validation happen in an API?

Validation belongs at system boundaries: API route handlers, form submissions, external service responses, and environment variable loading. Internal functions that share type contracts should trust already-validated data rather than re-validating.

Should I use PUT or PATCH for updating resources?

Use PATCH for partial updates where only provided fields change, which is what clients typically want. PUT requires sending the full object every time, making it fragile for resources with many fields.

What is Hyrum's Law and why does it matter for API design?

Hyrum's Law states that all observable behaviors of a system will be depended on by someone, regardless of the documented contract. This means undocumented quirks, error text, and ordering become de facto commitments, so design intentionally about what you expose.