Q284: API Contracts Pagination Filtering and Client Data Access
What Interviewers Want To Evaluate
Interviewers want to know whether you can design API contracts that support real frontend workflows.
They are checking pagination, filtering, sorting, partial loading, errors, caching, authorization, and client ergonomics.
Short Interview Answer
Frontend-friendly API contracts should match user workflows while preserving backend correctness. I define clear request and response shapes, pagination strategy, filtering and sorting semantics, error contracts, authorization behavior, cache rules, and loading states. For large lists, I prefer cursor pagination when data changes frequently, URL-driven filters for shareability, stable IDs for rendering, and typed contracts with runtime validation at boundaries.
Detailed Interview Answer
APIs are product surfaces.
If an API is awkward, the UI becomes awkward.
A good frontend-facing API answers:
what data is available?
how do I request a slice?
how do I filter it?
how do I sort it?
how do I know there is more?
how do I mutate it?
how do errors look?
what can this user access?
Request Shape
A list request may include:
query
filters
sort
cursor
limit
view mode
include fields
locale
Keep names stable and meaningful.
Avoid leaking internal database names into public API if they are not part of the product language.
Response Shape
A list response often includes:
items
nextCursor
totalCount if affordable
facets
permissions
serverTime
requestId
For each item, include stable IDs.
Stable IDs help React keys, optimistic updates, and cache normalization.
Pagination
Pagination choices:
offset pagination
cursor pagination
page-number pagination
infinite scroll
load more
virtualized window
Offset pagination is simple but can break with rapidly changing data.
Cursor pagination is better for feeds and changing lists.
Page numbers are useful when users need direct navigation.
Filtering
Filters should be:
URL-friendly
composable
validated
documented
permission-aware
For example:
?topic=security&difficulty=staff&status=unread
If filters are shareable, they belong in the URL.
Sorting
Sorting needs stable semantics.
Examples:
newest
oldest
most relevant
highest priority
recently updated
If sorting by a non-unique field, the API may need a tie-breaker.
This avoids duplicate or missing rows across pages.
Field Selection
Sometimes views need different data.
Options:
separate endpoints
include parameters
GraphQL selection
BFF-shaped response
Do not overfetch sensitive or heavy fields in every list row.
List views usually need summaries.
Detail views need depth.
Error Contracts
Errors should help UI recover.
Include:
status
code
message
field errors
retryable
request ID
Distinguish:
401 unauthenticated
403 forbidden
404 missing
409 conflict
422 validation
429 rate limit
500 server failure
Client Data Access
Frontend data access should avoid scattering fetch logic everywhere.
Use:
typed API client
shared error parser
runtime schema validation for external data
cache policy by endpoint
request cancellation
deduplication
retry rules
This keeps components focused on UI.
Interview Example
If asked, "Design API access for a question list with filters," answer:
URL stores filters and sort
API accepts topic, volume, difficulty, status, query, cursor, limit
response returns items, nextCursor, facets, and requestId
client caches by full query key
list uses stable question IDs
errors distinguish forbidden from empty
Common Mistakes
Common mistakes include:
fetching all records for large lists
using array index as key
not defining error shape
not putting shareable filters in URL
offset pagination for volatile feeds without thought
returning sensitive fields in list summaries
not validating query params
not documenting sorting semantics
Senior-Level Framing
The senior framing:
"I design API contracts from the UI workflow backward, then make pagination, filtering, sorting, errors, caching, and authorization explicit so the frontend remains predictable at scale."
Practice Prompt
Design a question-search API for Learning Studio.
Define:
request params
response shape
pagination
filters
sorts
errors
cache key
URL state mapping
Final Mental Model
Frontend API design is not just fetching data.
It is designing the contract that makes product interaction reliable, fast, safe, and understandable.