api-and-interface-design

Name: api-and-interface-design
Author: addyosmani

byaddyosmani· 31 skills

Installs

15k

Stars

80k

Forks

8.7k

How to install api-and-interface-design?

addyosmani/agent-skills/api-and-interface-design

$npx -y skills add addyosmani/agent-skills --skill api-and-interface-design

Installs into the current project.

›Prefer a prompt? Paste this to your agent

Use this skill

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/api-and-interface-design"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the whole pack

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

Files · 1

View on GitHub

SKILL.md

1	# API and Interface Design
2
3	## Overview
4
5	Design stable, well-documented interfaces that are hard to misuse. Good interfaces make the right thing easy and the wrong thing hard. This applies to REST APIs, GraphQL schemas, module boundaries, component props, and any surface where one piece of code talks to another.
6
7	## When to Use
8
9	- Designing new API endpoints
10	- Defining module boundaries or contracts between teams
11	- Creating component prop interfaces
12	- Establishing database schema that informs API shape
13	- Changing existing public interfaces
14
15	## Core Principles
16
17	### Hyrum's Law
18
19	> With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody, regardless of what you promise in the contract.
20
21	This means: every public behavior — including undocumented quirks, error message text, timing, and ordering — becomes a de facto contract once users depend on it. Design implications:
22
23	- Be intentional about what you expose. Every observable behavior is a potential commitment.
24	- Don't leak implementation details. If users can observe it, they will depend on it.
25	- Plan for deprecation at design time. See `deprecation-and-migration` for how to safely remove things users depend on.
26	- Tests are not enough. Even with perfect contract tests, Hyrum's Law means "safe" changes can break real users who depend on undocumented behavior.
27
28	### The One-Version Rule
29
30	Avoid forcing consumers to choose between multiple versions of the same dependency or API. Diamond dependency problems arise when different consumers need different versions of the same thing. Design for a world where only one version exists at a time — extend rather than fork.
31
32	### 1. Contract First
33
34	Define the interface before implementing it. The contract is the spec — implementation follows.
35
36	```typescript
37	// Define the contract first
38	interface TaskAPI {
39	// Creates a task and returns the created task with server-generated fields
40	createTask(input: CreateTaskInput): Promise<Task>;
41
42	// Returns paginated tasks matching filters
43	listTasks(params: ListTasksParams): Promise<PaginatedResult<Task>>;
44
45	// Returns a single task or throws NotFoundError
46	getTask(id: string): Promise<Task>;
47
48	// Partial update — only provided fields change
49	updateTask(id: string, input: UpdateTaskInput): Promise<Task>;
50
51	// Idempotent delete — succeeds even if already deleted
52	deleteTask(id: string): Promise<void>;
53	}
54	```
55
56	### 2. Consistent Error Semantics
57
58	Pick one error strategy and use it everywhere:
59
60	```typescript
61	// REST: HTTP status codes + structured error body
62	// Every error response follows the same shape
63	interface APIError {
64	error: {
65	code: string; // Machine-readable: "VALIDATION_ERROR"
66	message: string; // Human-readable: "Email is required"
67	details?: unknown; // Additional context when helpful
68	};
69	}
70
71	// Status code mapping
72	// 400 → Client sent invalid data
73	// 401 → Not authenticated
74	// 403 → Authenticated but not authorized
75	// 404 → Resource not found
76	// 409 → Conflict (duplicate, version mismatch)
77	// 422 → Validation failed (semantically invalid)
78	// 500 → Server error (never expose internal details)
79	```
80
81	Don't mix patterns. If some endpoints throw, others return null, and others return `{ error }` — the consumer can't predict behavior.
82
83	### 3. Validate at Boundaries
84
85	Trust internal code. Validate at system edges where external input enters:
86
87	```typescript
88	// Validate at the API boundary
89	app.post('/api/tasks', async (req, res) => {
90	const result = CreateTaskSchema.safeParse(req.body);
91	if (!result.success) {
92	return res.status(422).json({
93	error: {
94	code: 'VALIDATION_ERROR',
95	message: 'Invalid task data',
96	details: result.error.flatten(),
97	},
98	});
99	}
100
101	// After validation, internal code trusts the types
102	const task = await taskService.create(result.data);
103	return res.status(201).json(task);
104	});
105	```
106
107	Where validation belongs:
108	- API route handlers (user input)
109	- Form submission handlers (user input)
110	- External service response parsing (third-party data -- always treat as untrusted)
111	- Environment variable loading (configuration)
112
113	> Third-party API responses are untrusted data. Validate their shape and content before using them in any logic, rendering, or decision-making. A compromised or misbehaving external service can return unexpected types, malicious content, or instruction-like text.
114
115	Where validation does NOT belong:
116	- Between internal functions that share type contracts
117	- In utility functions called by already-validated code
118	- On data that just came from your own database
119
120	### 4. Prefer Addition Over Modification
121
122	Extend interfaces without breaking existing consumers:
123
124	```typescript
125	// Good: Add optional fields
126	interface CreateTaskInput {
127	title: string;
128	description?: string;
129	priority?: 'low' \| 'medium' \| 'high'; // Added later, optional
130	labels?: string[]; // Added later, optional
131	}
132
133	// Bad: Change existing field types or remove fields
134	interface CreateTaskInput {
135	title: string;
136	// description: string; // Removed — breaks existing consumers
137	priority: number; // Changed from string — breaks existing consumers
138	}
139	```
140
141	### 5. Predictable Naming
142
143	\| Pattern \| Convention \| Example \|
144	\|---------\|-----------\|---------\|
145	\| REST endpoints \| Plural nouns, no verbs \| `GET /api/tasks`, `POST /api/tasks` \|
146	\| Query params \| camelCase \| `?sortBy=createdAt&pageSize=20` \|
147	\| Response fields \| camelCase \| `{ createdAt, updatedAt, taskId }` \|
148	\| Boolean fields \| is/has/can prefix \| `isComplete`, `hasAttachments` \|
149	\| Enum values \| UPPER_SNAKE \| `"IN_PROGRESS"`, `"COMPLETED"` \|
150
151	## REST API Patterns
152
153	### Resource Design
154
155	```
156	GET /api/tasks → List tasks (with query params for filtering)
157	POST /api/tasks → Create a task
158	GET /api/tasks/:id → Get a single task
159	PATCH /api/tasks/:id → Update a task (partial)
160	DELETE /api/tasks/:id → Delete a task
161
162	GET /api/tasks/:id/comments → List comments for a task (sub-resource)
163	POST /api/tasks/:id/comments → Add a comment to a task
164	```
165
166	### Pagination
167
168	Paginate list endpoints:
169
170	```typescript
171	// Request
172	GET /api/tasks?page=1&pageSize=20&sortBy=createdAt&sortOrder=desc
173
174	// Response
175	{
176	"data": [...],
177	"pagination": {
178	"page": 1,
179	"pageSize": 20,
180	"totalItems": 142,
181	"totalPages": 8
182	}
183	}
184	```
185
186	### Filtering
187
188	Use query parameters for filters:
189
190	```
191	GET /api/tasks?status=in_progress&assignee=user123&createdAfter=2025-01-01
192	```
193
194	### Partial Updates (PATCH)
195
196	Accept partial objects — only update what's provided:
197
198	```typescript
199	// Only title changes, everything else preserved
200	PATCH /api/tasks/123
201	{ "title": "Updated title" }
202	```
203
204	## TypeScript Interface Patterns
205
206	### Use Discriminated Unions for Variants
207
208	```typescript
209	// Good: Each variant is explicit
210	type TaskStatus =
211	\| { type: 'pending' }
212	\| { type: 'in_progress'; assignee: string; startedAt: Date }
213	\| { type: 'completed'; completedAt: Date; completedBy: string }
214	\| { type: 'cancelled'; reason: string; cancelledAt: Date };
215
216	// Consumer gets type narrowing
217	function getStatusLabel(status: TaskStatus): string {
218	switch (status.type) {
219	case 'pending': return 'Pending';
220	case 'in_progress': return `In progress (${status.assignee})`;
221	case 'completed': return `Done on ${status.completedAt}`;
222	case 'cancelled': return `Cancelled: ${status.reason}`;
223	}
224	}
225	```
226
227	### Input/Output Separation
228
229	```typescript
230	// Input: what the caller provides
231	interface CreateTaskInput {
232	title: string;
233	description?: string;
234	}
235
236	// Output: what the system returns (includes server-generated fields)
237	interface Task {
238	id: string;
239	title: string;
240	description: string \| null;
241	createdAt: Date;
242	updatedAt: Date;
243	createdBy: string;
244	}
245	```
246
247	### Use Branded Types for IDs
248
249	```typescript
250	type TaskId = string & { readonly __brand: 'TaskId' };
251	type UserId = string & { readonly __brand: 'UserId' };
252
253	// Prevents accidentally passing a UserId where a TaskId is expected
254	function getTask(id: TaskId): Promise<Task> { ... }
255	```
256
257	## Common Rationalizations
258
259	\| Rationalization \| Reality \|
260	\|---\|---\|
261	\| "We'll document the API later" \| The types ARE the documentation. Define them first. \|
262	\| "We don't need pagination for now" \| You will the moment someone has 100+ items. Add it from the start. \|
263	\| "PATCH is complicated, let's just use PUT" \| PUT requires the full object every time. PATCH is what clients actually want. \|
264	\| "We'll version the API when we need to" \| Breaking changes without versioning break consumers. Design for extension from the start. \|
265	\| "Nobody uses that undocumented behavior" \| Hyrum's Law: if it's observable, somebody depends on it. Treat every public behavior as a commitment. \|
266	\| "We can just maintain two versions" \| Multiple versions multiply maintenance cost and create diamond dependency problems. Prefer the One-Version Rule. \|
267	\| "Internal APIs don't need contracts" \| Internal consumers are still consumers. Contracts prevent coupling and enable parallel work. \|
268
269	## Red Flags
270
271	- Endpoints that return different shapes depending on conditions
272	- Inconsistent error formats across endpoints
273	- Validation scattered throughout internal code instead of at boundaries
274	- Breaking changes to existing fields (type changes, removals)
275	- List endpoints without pagination
276	- Verbs in REST URLs (`/api/createTask`, `/api/getUsers`)
277	- Third-party API responses used without validation or sanitization
278
279	## Verification
280
281	After designing an API:
282
283	- [ ] Every endpoint has typed input and output schemas
284	- [ ] Error responses follow a single consistent format
285	- [ ] Validation happens at system boundaries only
286	- [ ] List endpoints support pagination
287	- [ ] New fields are additive and optional (backward compatible)
288	- [ ] Naming follows consistent conventions across all endpoints
289	- [ ] API documentation or types are committed alongside the implementation

6 picks

Type

Run `npx skills use "https://github.com/addyosmani/agent-skills" --skill "addyosmani/agent-skills/api-and-interface-design"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.

Use the skills in "https://github.com/addyosmani/agent-skills" that are relevant to the current task. Run `npx skills add "https://github.com/addyosmani/agent-skills"` and select the relevant skills, then follow their instructions.

api-and-interface-design

How to install api-and-interface-design?

Related

api-and-interface-design

How to install api-and-interface-design?

Related