RESTful API Design and HTTP Fundamentals Questions

Understanding REST architectural principles including resource-based URLs, proper HTTP methods (GET for safe retrieval, POST for creation, PUT for updates, DELETE for deletion), appropriate status codes (200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error), and stateless communication patterns. Ability to design simple API endpoints following REST conventions.

EasyTechnical

65 practiced

Explain HTTP content negotiation. What are the roles of the Accept and Content-Type headers from the client and server perspectives? Describe how a server should behave when multiple formats are supported and when the client sends an Accept header the server cannot satisfy.

Sample Answer

**Quick definition**HTTP content negotiation lets client and server agree on the representation (media type, charset, language) of a resource. It’s common in REST APIs to support JSON, XML, HTML, etc.

**Roles of headers**- Accept (client): tells server which MIME types the client prefers, optionally with q= weights.- Content-Type (server response): tells the client the actual MIME type of the response body. The client also sends Content-Type on request bodies.

Example Accept header:

http

Accept: application/json, text/plain;q=0.8, */*;q=0.1

**Server behavior**- When multiple formats supported: perform server-driven or server/agent negotiation. Use Accept to pick the best match by q values and capability; default to a sensible format (e.g., application/json) if multiple equal.- When Accept cannot be satisfied: respond with 406 Not Acceptable, or more commonly return a default representation (200 OK) with Content-Type indicating that default and document this behavior in API docs.

**Best practices**- Prefer explicit Accept parsing and deterministic fallback.- Include Content-Type and proper charset; support wildcard ranges if reasonable.

EasyTechnical

113 practiced

Classify the common HTTP methods GET, POST, PUT, PATCH, DELETE, HEAD, and OPTIONS in terms of safety and idempotency. For each method give a short example of when it is appropriate in a REST API and explain why safety or idempotency matters for client retries and caching.

HardSystem Design

73 practiced

Design REST endpoints and a database schema for Authors, Books, and Reviews where Authors have many Books and Books have many Reviews. Address API choices for nested routes versus standalone resources, response shapes to avoid N+1 queries, and SQL optimization strategies such as joins, batching, and pagination for list endpoints.

Sample Answer

**Clarify requirements & constraints**- Public REST to support listing, detail, create/update/delete for Authors, Books, Reviews.- Support nested access (books by author, reviews by book), efficient list endpoints, and avoid N+1.

**API design (endpoints & choices)**- Standalone resources (canonical): - GET /authors - POST /authors - GET /authors/{author_id} - PUT /authors/{author_id} - DELETE /authors/{author_id} - GET /books - POST /books - GET /books/{book_id} - PUT /books/{book_id} - DELETE /books/{book_id} - GET /books/{book_id}/reviews - POST /books/{book_id}/reviews - GET /reviews/{review_id} - PUT /reviews/{review_id} - DELETE /reviews/{review_id}- Nested routes for convenience/search: - GET /authors/{author_id}/books (alias of /books?author_id=) - GET /books/{book_id}/reviews (primary for reviews under a book)- Use query params for filtering/sorting/pagination: ?page=1&per_page=20&sort=published_at&include=author,reviews_count

**Response shapes to avoid N+1**- Support include expansion and minimal fields; default list endpoints return lightweight rows.- Example: GET /books?include=author,reviews_count returns: - book fields + embedded author {id,name} + reviews_count integer- Use IDs arrays instead of full nested objects when large.

**SQL & ORM strategies**- Use joins and aggregates for lists to compute counts in one query:

sql

SELECT b.*, a.id AS author_id, a.name AS author_name, COALESCE(r.review_count,0) AS reviews_count
FROM books b
JOIN authors a ON b.author_id = a.id
LEFT JOIN (
  SELECT book_id, COUNT(*) AS review_count
  FROM reviews
  GROUP BY book_id
) r ON r.book_id = b.id
WHERE b.published = true
ORDER BY b.published_at DESC
LIMIT 20 OFFSET 0;

- For including recent N reviews per book, use window functions:

sql

SELECT * FROM (
  SELECT r.*, ROW_NUMBER() OVER (PARTITION BY r.book_id ORDER BY r.created_at DESC) rn
  FROM reviews r
  WHERE r.book_id IN (...)
) t WHERE rn <= 3;

- ORM best practices: use eager-loading (includes/preload), avoid per-row lazy loads, batch queries for associations.- Pagination: cursor-based for large datasets; use OFFSET for small pages, and indexed sort columns for performance.- Indexing: indexes on foreign keys (books.author_id, reviews.book_id), on sorting columns (books.published_at), and composite indexes for common filters.- Caching: cache counts or expensive aggregations with TTL; use CDN for public list endpoints.

**Trade-offs**- Nested endpoints are convenient but duplicate surface area; keep canonical standalone resources and make nested endpoints light proxies.- Eager-loading increases payload size; allow clients to opt-in via include= to balance N+1 vs response size.

**Monitoring & validation**- Measure slow queries, track N+1 via instrumentation, add request-level throttling for heavy includes.

HardSystem Design

62 practiced

Design a webhook delivery system for a SaaS platform that must reliably deliver events to third-party endpoints. Cover message signing, replay protection, at-least-once delivery semantics, retry/backoff policy with jitter, dead-letter queueing, ordering guarantees or lack thereof, visibility for consumers, and scaling across regions. Provide suggested headers and payload structure.

Sample Answer

**Clarify requirements & guarantees**- Deliver events reliably to third‑party HTTPS endpoints with at‑least‑once semantics, message signing, replay protection, retries with jitter, DLQ, visibility, and multi‑region scaling. Ordering not strictly required unless subscriber opts in.

**High-level architecture**- Event producer → Internal event bus (Kafka/Rabbit or Kinesis) → Delivery workers (stateless) → Per‑subscriber delivery queue (backed by durable storage) → DLQ service → Admin UI / metrics (Prometheus/Grafana, tracing).

**Core components & responsibilities**- Ingest: validate, enrich, store event in durable store and publish to bus.- Router: fan‑out to subscriber queues (SQS/SNS/Kafka topics per region).- Delivery workers: pick next pending message, sign, send, handle response, ack/unack.- Retry manager: exponential backoff with jitter, per‑subscriber limits, moves to DLQ after N attempts.- DLQ: durable store (S3/RDS) + reprocess API.- Visibility: UI + API showing status, attempts, logs, last response, trace IDs.

**Message signing & replay protection**- Sign payload with HMAC SHA256 using per‑subscriber secret. Header:

json

{
    "X-Webhook-Id": "evt_12345",
    "X-Webhook-Signature": "v1=hex(hmac_sha256(secret, timestamp + '.' + body))",
    "X-Webhook-Timestamp": "2026-03-02T12:34:56Z",
    "X-Webhook-Nonce": "uuid-v4",
    "X-Webhook-Attempt": "3"
  }

- Receiver verifies signature and timestamp (reject if > allowed skew) and checks nonce/cache for replay. Store nonces for TTL (e.g., 24h) in fast key-value store (Redis).

**At‑least‑once & ordering**- At‑least‑once: ack only after 2xx. Non‑2xx or timeouts trigger retry.- Ordering options: - Default: no ordering — parallelism for scale. - Ordered delivery (opt‑in): use per‑subscriber ordered queue (single consumer or partition key). Provide backpressure and delayed retries to maintain order; deadlock risk managed via slow consumer timeouts.

**Retry/backoff with jitter**- Use exponential backoff: backoff = base * 2^(attempt-1)- Add full jitter: sleep = random(0, backoff)- Example params: base 1s, max 1h, max attempts 10. Immediate retry on 5xx with incremental backoff; don't retry on 4xx (except 429 -> retry-after).- Respect Retry-After header from client; rate‑limit per subscriber.

**Dead‑letter queuing**- After max attempts, move message to DLQ with metadata (attempts, last_error, timestamps). Expose replay/retry APIs and retention policy.

**Scaling across regions**- Deploy regional ingestion and delivery clusters close to subscriber endpoints; use global event bus + replication or use region affinity per subscriber. Use consistent hashing to route to region; failover cross‑region if local region down. Replicate DLQ metadata to central store.

**Observability & consumer visibility**- Expose APIs/UI: per‑event delivery status, attempt history, latest response body/status, replay button, subscriber config. Emit metrics (success rate, p99 latency), traces with trace_id header.

**Suggested payload**

json

{
  "id": "evt_12345",
  "type": "order.created",
  "occurred_at": "2026-03-02T12:34:56Z",
  "data": { "order_id": "ord_987", "amount": 123.45 },
  "meta": { "source": "orders-service", "region": "us-east-1" }
}

**Notes & tradeoffs**- At‑least‑once simplifies reliability but requires idempotency by receivers; provide idempotency key (X-Webhook-Id).- Ordered delivery sacrifices throughput/parallelism.- Keep secrets per subscriber, rotate regularly, support asymmetric signatures if needed.

EasyTechnical

76 practiced

Explain statelessness in the context of REST APIs. What does it mean for server and client responsibilities? Describe acceptable server-side state (if any), how statelessness affects horizontal scaling, and common patterns to handle session-like needs without server session state.

Unlock Full Question Bank

Get access to hundreds of RESTful API Design and HTTP Fundamentals interview questions and detailed answers.

Join thousands of developers preparing for their dream job.