api-and-interface-design

Designs stable REST APIs, TypeScript contracts, and module boundaries with consistent error semantics.

Updated Jul 10, 2026
One-click install
npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill api-and-interface-design-codecrafteradi2006
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-and-interface-design
Source: https://github.com/CodeCrafterAdi2006/Ink-and-Code/tree/main/Skills/api-and-interface-design
Command: npx skills add https://github.com/CodeCrafterAdi2006/Ink-and-Code --skill api-and-interface-design-codecrafteradi2006

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Poorly designed interfaces create breaking changes, inconsistent error handling, and hidden dependencies that frustrate consumers and multiply maintenance cost. 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 typed interfaces (REST endpoints, TypeScript contracts, component props) before writing implementation code. - Consistent Error Semantics: Establish a single error format with structured codes, HTTP status mapping, and boundary-only validation. - Backward-Compatible Evolution: Apply additive-only changes, pagination from day one, discriminated unions, and branded ID types to prevent breaking consumers. - Use Case: When creating a new /api/tasks endpoint, use this Skill to define the input/output schemas, pagination shape, error format, and naming conventions so frontend and backend teams can build in parallel against a stable contract. ## Quick Start Ask the AI to design a REST API contract for a new resource, including typed inputs, outputs, error responses, and pagination, following the api-and-interface-design guidelines.

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?

Design REST APIs by preferring addition over modification: add only optional fields, never change existing field types or remove fields. Use plural noun endpoints, PATCH for partial updates, and paginate list endpoints from the start.

What is the best way to structure API error responses?

Structure API error responses with one consistent format: a machine-readable code, a human-readable message, and optional details. Map errors to standard HTTP status codes like 400, 401, 403, 404, 409, 422, and 500 across every endpoint.

Should I validate data inside internal functions or at API boundaries?

Validate only at system boundaries where external input enters: API route handlers, form submissions, third-party responses, and environment variables. Internal functions that share type contracts should trust already-validated data to avoid scattered redundant checks.

When should I use PATCH vs PUT for API updates?

Use PATCH for partial updates where only provided fields change, which is what clients actually need. PUT requires sending the full object every time, making it fragile and verbose for typical update operations.

Why should third-party API responses be validated before use?

Third-party API responses are untrusted data that can contain unexpected types, malicious content, or instruction-like text from compromised services. Validate their shape and content before using them in logic, rendering, or decision-making.