API Design
48 bites tagged API Design — interview questions with model answers, and 60-second explainers.
Using personas to drive technical decisions
Derive constraints like device, network, accessibility from personas; let them shape framework, payload shape, performance budgets. Connecting user context to engineering choices.
Unifying divergent native video player props
A JS component accepts a unified source prop, then uses Platform.OS to map it into each native view's expected props before rendering. designing a cross-platform wrapper over divergent native views.
Designing an API for power vs novice personas
Power users want control, batching, and precise errors; novices want defaults, guardrails, and guidance; both want consistency. Whether personas drive concrete API tradeoffs.
Public API design versus internal API design
Public needs strict versioning, long deprecation, scoped auth like OAuth and API keys, and polished docs; internal can move faster. public APIs are long-lived contracts.
Nested routes versus query params for related resources
Nested routes express ownership and scope clearly, query params on the flat resource are flexible for filtering and combining. REST relationship modeling tradeoffs.
API versioning: URL vs header strategies
Version via URL path (/v1/), a custom or Accept header, or a query param; URL is visible and cache-friendly, headers keep URLs clean but are less discoverable. managing breaking changes.
Centralized error handling in an Express API
A final four-arg error middleware, an asyncHandler wrapper to funnel promise rejections via next, a custom error class with statusCode, returning uniform JSON. designing one error path.
Idempotency: PUT vs POST in REST
Idempotent means repeated identical requests leave the same server state; PUT is idempotent, POST is not. Use PUT to overwrite a resource at a known URL. understanding idempotency.
Status codes for successful POST and GET
201 Created for a successful POST (ideally with a Location header), 200 OK for a successful GET returning data. correct 2xx semantics. returning 200 for every success or 204 when a body is sent.
Designing a flexible yet usable DataTable API
Sensible defaults, compound or slot-based composition for flexibility, props for common cases. Component API design judgment. Defaulting to one giant config object or exposing every internal as a flat prop without layering.
Deciding whether a one-off variant belongs in core
Weigh reuse and consistency against maintenance cost, then decide with a shared-need bar and escape hatches for local cases. Whether you guard the core against bloat. Reflexively adding every requested variant to core.
Enforcing an accessible name on icon-only buttons
Require aria-label via the type system for icon-only variants, warn at runtime, decorate the icon as aria-hidden. API design that guarantees an accessible name. trusting developers to remember a label on icon buttons.
Architecting a composable DataTable API
Separate a headless data/state core from rendering, use a column-definition config with custom cell renderers, expose composition over dozens of flags. avoiding prop-bloat in a complex component.
Structuring release notes for breaking API changes
Lead with a summary and why, group breaking changes with before/after migration steps, give deprecation timelines and an upgrade path. communicating breaking changes. burying breaking changes in a flat changelog.
Cross-platform stateful onboarding sync
Store onboarding state server-side keyed to the user, expose idempotent step-completion APIs, and push updates to other clients. server-authoritative state with multi-client sync.
Composite components versus layout primitives
Primitives give flexibility and composition, composites enforce consistency, choose by reuse and variation. balancing consistency against flexibility in API design.
How would you automatically audit WCAG AA contrast in Figma?
This tests Figma plugin vs REST API color extraction limits. Good answers contrast live traversal with export-based analysis, cite WCAG AA ratios of 4.5:1 and 3:1, and note opacity. A red flag is assuming the REST API can sample pixels without image export.
How do you handle an API returning 200 for success and failure?
This tests TypeScript narrowing and runtime validation of ambiguous 200 responses. A strong answer uses a discriminated union, narrows with a type guard, and validates shape before branching. Red flag: casting the body with as and skipping runtime checks.
Build a typesafe ApiRoute type using template literal types
Tests type-level string composition with template literals. Good answer: define a Resource union, interpolate it into /api/v1/ paths, then union with the /{id} variant. Red flag: suggesting runtime regex or plain string instead of literal types.
Write a generic ApiResponse<T> type with success and error states
Define two interfaces sharing a status literal, one with data: T and the other with error: { code; message; }. modeling exclusive states with discriminated unions and generics.
How would you use an enum to represent API statuses?
What it tests: TypeScript enum runtime behavior and API serialization trade-offs. Strong answer: define a string enum with exact API values, contrast readable wire format vs opaque numeric values.
How do you type a function with two possible response shapes?
This checks TypeScript union types for API responses. Define a union of Product[] and a message object, use a type guard to narrow it at runtime, and return that.
How do you directly modify FastAPI's generated OpenAPI dictionary?
Tests deep FastAPI lifecycle knowledge. Override app.openapi: save the original, call it to get the dict, mutate it, cache on app.openapi_schema, and return. Red flag: rewriting /openapi.json in middleware or touching the schema cache directly.
Add a custom x- field to a FastAPI path operation schema
Tests knowledge of FastAPI's built-in OpenAPI extension hook. Answer: cite the path operation decorator's extra-schema dict (OpenAPI Extra) to merge x-internal-id directly. Red flag: proposing manual JSON editing or schema post-processing.
Get API Design bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.