api-and-interface-design

Design stable REST APIs, TypeScript interfaces, and module contracts with consistent error semantics.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Public interfaces become hard to change once consumers depend on them, and inconsistent error handling, missing pagination, or breaking changes create fragile integrations. This Skill guides the design of stable APIs and module boundaries so interfaces are hard to misuse and safe to evolve. ## Core Features & Use Cases - Contract-First Design: Define typed input/output contracts before implementation, including discriminated unions, branded ID types, and input/output separation. - REST API Conventions: Apply consistent resource naming, pagination, filtering, PATCH semantics, and a single structured error format with proper HTTP status codes. - Boundary Validation: Validate external input at system edges (route handlers, third-party responses, environment variables) while trusting internal typed code. - Use Case: When adding a new endpoint to a task management service, use this Skill to define the typed contract, choose status codes, add pagination to list endpoints, and verify backward compatibility before writing implementation code. ## Quick Start Use the api-and-interface-design skill to review my planned REST endpoints for the tasks service and check them for consistency and backward compatibility.

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 clients?▼

Prefer additive changes: add new optional fields instead of modifying or removing existing ones, and use PATCH for partial updates. Define typed contracts first and treat every observable behavior as a commitment under Hyrum's Law.

What HTTP status codes should a REST API use for errors?▼

Use 400 for invalid client data, 401 for missing authentication, 403 for authorization failures, 404 for missing resources, 409 for conflicts, 422 for semantic validation failures, and 500 for server errors. Pair each with a consistent structured error body containing code, message, and optional details.

Where should input validation happen in an application?▼

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

Should I validate responses from third-party APIs?▼

Yes, third-party API responses are untrusted data. Validate their shape and content before using them in logic or rendering, since a compromised or misbehaving external service can return unexpected types or malicious content.

When should I use PATCH instead of PUT for updates?▼

Use PATCH when clients should send only the fields they want to change, which is the common case. PUT requires sending the full object every time, making it cumbersome for partial updates and increasing the risk of overwriting unchanged fields.