api-and-interface-design

Designs stable REST APIs, TypeScript contracts, and idempotent endpoints with consistent error semantics.

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/MSC72m/DevForge --skill api-and-interface-design-msc72m
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/MSC72m/DevForge/tree/main/skills/api-and-interface-design
Command: npx skills add https://github.com/MSC72m/DevForge --skill api-and-interface-design-msc72m

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Poorly designed interfaces create breaking changes, inconsistent error handling, and duplicate side effects that erode consumer trust. This Skill guides the design of stable, hard-to-misuse APIs and module boundaries before implementation begins. ## Core Features & Use Cases - Contract-First Design: Define TypeScript interfaces, discriminated unions, and branded ID types before writing implementation code. - REST API Patterns: Apply conventions for resource naming, pagination, filtering, PATCH partial updates, and consistent structured error responses. - Idempotency Implementation: Honour Idempotency-Key headers with atomic claims via unique constraints, payload hash guards, and deliberate in-flight duplicate strategies. - Use Case: When adding a payments endpoint, use this Skill to derive a stable idempotency key from the order ID, claim it atomically against a unique constraint, and reject reused keys with mismatched payloads. ## Quick Start Use the api-and-interface-design skill to review my new REST endpoint design for consistency, pagination, and idempotency 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 doesn't break existing consumers?▼

Prefer addition over modification: add new fields as optional and never change existing field types or remove fields. Define the contract first with typed input and output schemas, and plan for deprecation at design time since Hyrum's Law means users depend on every observable behavior.

How to implement idempotency keys for payment or POST endpoints?▼

Derive the key from an immutable identifier like the order ID, never a UUID or timestamp regenerated per attempt. Claim it atomically with a unique constraint insert rather than a check-then-act, and reject the same key reused with a different payload with a loud error.

Where should input validation happen in an API?▼

Validate only at system boundaries: route handlers, form submissions, environment variable loading, and third-party API responses. Internal functions sharing type contracts should trust already-validated data rather than re-validating throughout the codebase.

Should I use PUT or PATCH for updating resources?▼

Use PATCH for partial updates where only provided fields change, which is what clients actually want. PUT requires sending the full object every time, making it fragile for consumers and prone to overwriting fields unintentionally.

What are common API design mistakes to avoid?▼

Red flags include verbs in URLs, inconsistent error formats across endpoints, list endpoints without pagination, breaking changes to existing fields, and accepting an Idempotency-Key header without atomically storing and honouring it.