api-design-edho-ferdian

Designs REST API contracts, endpoint conventions, and versioning policies before implementation.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/edhoferdian/EEF --skill api-design-edho-ferdian-edhoferdian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: api-design-edho-ferdian
Source: https://github.com/edhoferdian/EEF/tree/main/.agents/skills/api-design-edho-ferdian
Command: npx skills add https://github.com/edhoferdian/EEF --skill api-design-edho-ferdian-edhoferdian

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? APIs designed ad hoc drift between client and server, leak database internals, and break consumers on every change. This Skill provides a disciplined design-time workflow for shaping REST endpoints and maintaining one authoritative contract artifact so both sides of a boundary stay in sync. ## Core Features & Use Cases - REST Shape Conventions: Resource naming, HTTP status-code semantics, response envelopes, pagination strategy (offset vs. cursor), filtering, rate-limit headers, and versioning with Sunset policy. - Contract-First Evolution: One canonical artifact (OpenAPI, AsyncAPI, Protobuf, JSON Schema) per boundary, generated types/clients, a step-by-step change protocol, and named anti-patterns like treating compile-time types as proof of contract correctness. - MCP Tool Surface Design: Model-consumer-specific rules for schema-first tool definitions, description-as-contract, idempotency, and transport choice. - Use Case: When starting a new API surface or changing an existing contract, walk the workflow to decide endpoint shape, pick the pagination strategy with a stated reason, and pass the five-gate reflection checklist before presenting the design. ## Quick Start Ask the assistant to design the REST API contract for a new feature, including endpoints, status codes, pagination, and an OpenAPI artifact.

Frequently Asked Questions about api-design-edho-ferdian

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

FAQPage Schema
How do I design a REST API contract before writing code?

Start from consumer jobs rather than the database schema, define resource naming, status codes, and error shapes, then record everything in one authoritative OpenAPI artifact. Generate client types from that artifact instead of hand-writing them.

Should I use offset or cursor pagination for my API?

Use offset pagination for admin dashboards and small datasets under 10K rows where jump-to-page matters. Use cursor pagination for feeds, infinite scroll, and frequently-mutated datasets, since offset can skip or duplicate rows under concurrent writes.

How do I change an API contract without breaking existing consumers?

Follow the change protocol: propose the change, update the canonical artifact first, review the diff with affected consumers, regenerate types, then update implementations. Breaking changes require a new version or migration path, never a silent field repurpose.

When should I use this instead of system design or code review?

Use it at design time when shaping a specific API boundary. Broader trade-offs like monolith vs. microservices belong to system design, and reviewing an already-implemented endpoint belongs to code review.

Why are compile-time types not enough to verify an API contract?

A type annotation only checks the declared shape, not the actual runtime value, and casts like 'as unknown as X' bypass the checker entirely. Verify serialized responses at runtime with schema validation or contract tests against real output.