RESTful API And HTTP Service Design
Asked of: Software Engineer
Last updated

What's being tested
This tests whether you can turn HTTP semantics and REST API design into working, robust server code rather than just describing endpoints. Rippling cares because many product surfaces depend on reliable internal services: clear contracts, safe request handling, predictable errors, and maintainable routing matter as much as the happy-path implementation. Interviewers are probing for practical backend instincts: parsing protocol boundaries, choosing status codes, validating inputs, modeling resources, handling concurrency, and defending against common security bugs like path traversal. Strong answers make tradeoffs explicit and show how the design would evolve from an in-memory toy service to production-ready code.
Core knowledge
-
HTTP/1.1 request parsing starts with the request line:
METHOD path HTTP/1.1, followed by headers, a blank line, then an optional body. Never assume a singlerecv()contains the full request; read until\r\n\r\n, then useContent-Lengthfor the body. -
Status codes are part of the API contract. Use
200 OKfor successful reads,201 CreatedwithLocationfor new resources,204 No Contentfor successful deletes,400 Bad Requestfor malformed input,404 Not Found,409 Conflict,415 Unsupported Media Type, and500 Internal Server Error. -
RESTful resource modeling should use nouns and stable identifiers:
/questions,/questions/{id},/questions/{id}/answers. UseGETfor reads,POSTfor creation,PATCHorPUTfor updates, andDELETEfor removal; avoid RPC-style paths like/createQuestion. -
Idempotency distinguishes safe retries from duplicate writes.
GET,PUT, andDELETEshould be idempotent;POSTgenerally is not unless you add anIdempotency-Keypattern. In interviews, call out retry behavior even if you do not implement the full mechanism. -
Routing can start as a table mapping
(method, path_pattern)to handlers, with path parameters extracted by regex or segmented matching. A simple trie or ordered pattern matcher is enough for small services; avoid fragileif path.startswith(...)chains once nested resources appear. -
Input validation should happen at the boundary: parse
Content-Type, reject invalid JSON, enforce required fields, limit lengths, and normalize strings. For a Q&A service, validate question title/body, answer body, sort fields, page size, and ownership assumptions if authentication is in scope. -
Pagination and sorting prevent unbounded responses. Offset pagination with
limitandoffsetis simple but degrades for large offsets; cursor pagination using(created_at, id)is more stable. Caplimit, for examplemin(requested_limit, 100), to protect latency and memory. -
Concurrency models include one thread per connection, a fixed thread pool, or an event loop using
select,poll, orepoll. For an interview implementation, a bounded thread pool is easier to reason about; protect shared maps with locks or use immutable snapshots where possible. -
Persistence choices should match the exercise scope. An in-memory dictionary is acceptable for a minimal implementation, but call out restart loss and race conditions.
SQLiteis a strong next step for local durability;Postgresfits multi-user production services with indexes and transactions. -
Security basics matter even for local servers. Prevent path traversal by URL-decoding once, normalizing with something like
pathlib.Path.resolve(), and verifying the resolved path remains under the configured document root. Reject.., encoded traversal, and symlink escapes. -
Observability should include structured request logs with method, path, status, latency, and request id. Track counters for
2xx,4xx,5xx, and latency percentiles such asp95andp99; even in an interview, mention where logs would sit in the code path. -
Testing strategy should cover protocol and API behavior, not only handler logic. Include unit tests for routing and validation, integration tests using real sockets or an HTTP client, malformed request tests, concurrent request tests, and shutdown tests that verify no new connections are accepted.
Worked example
For Implement a minimal local HTTP server, a strong candidate first clarifies scope: “Do I need HTTP/1.1 keep-alive, static file serving, multiple routes, TLS, or just plain local localhost traffic?” Then they declare assumptions: support GET and maybe POST, parse Content-Length, return valid status lines and headers, serve from a configured root, and handle multiple clients concurrently. The answer can be organized around four pillars: socket lifecycle, request parsing, routing/response generation, and operational concerns like security, logging, and graceful shutdown. For sockets, they would describe bind(), listen(), accept(), then dispatch each connection to a worker thread or thread pool. For parsing, they would emphasize reading until the header delimiter, enforcing maximum header/body sizes, and producing 400 Bad Request instead of crashing on malformed input. For static file routes, they would explicitly normalize the requested path and verify it stays inside the document root before opening the file. One tradeoff to flag is thread-per-connection versus a bounded pool: thread-per-connection is simpler, but a pool prevents local resource exhaustion under many slow clients. They should close by saying that if they had more time, they would add keep-alive support, MIME type detection, request ids, integration tests with malformed packets, and a shutdown path that stops accepting new connections while allowing active requests to complete.
A second angle
For Implement a RESTful Q&A service, the focus shifts from protocol mechanics to resource design and application correctness. The same HTTP knowledge still applies, but the interviewer now expects clean endpoint definitions such as POST /questions, GET /questions/{id}, POST /questions/{id}/answers, and GET /questions?limit=20&cursor=.... A good solution defines data models, validation rules, status codes, and persistence boundaries before writing handlers. The main tradeoff is whether to keep data in memory for speed and simplicity or introduce SQLite/Postgres to get durability, uniqueness constraints, and transactions. The candidate should also cover pagination, sorting by created_at or score, consistent error response shape, and tests for missing fields, nonexistent IDs, and concurrent creates.
Common pitfalls
Pitfall: Treating HTTP as “read one string, split by spaces, return text.”
This misses protocol edge cases that backend interviewers care about: partial reads, headers, body length, malformed requests, and valid response formatting. A better answer acknowledges a minimal supported subset but still implements that subset correctly and defensively.
Pitfall: Designing endpoints around actions instead of resources.
Paths like POST /askQuestion, POST /editAnswer, and GET /getAllQuestions suggest weak REST instincts. Prefer resource-oriented paths, use the HTTP method to express the action, and make status codes and response bodies predictable.
Pitfall: Going too deep on production architecture before solving the local problem.
Jumping immediately to load balancers, service meshes, Kubernetes, or distributed databases can look like avoidance if the task is to implement a minimal server. Land the core implementation first, then briefly explain the next production steps: durability, authentication, rate limits, metrics, and deployment.
Connections
Interviewers may pivot from here into system design, especially API versioning, rate limiting, authentication, and data consistency. They may also move toward concurrency control, asking about locks, thread pools, race conditions, and graceful shutdown. For implementation-heavy rounds, expect follow-ups on testing strategy, malformed input handling, and debugging latency or 5xx spikes.
Further reading
-
RFC 9110: HTTP Semantics — authoritative reference for methods, status codes, headers, and core HTTP behavior.
-
OWASP Path Traversal — practical examples of file path attacks and defenses.
-
Microsoft REST API Guidelines — concrete conventions for resource naming, errors, pagination, and versioning.
Featured in interview prep guides
Practice questions
Related concepts
- API Integration And External Service DesignSystem Design
- Resilient API Aggregation And Operational DebuggingSoftware Engineering Fundamentals
- Robust Networking, REST, And Concurrency ControlSystem Design
- API Design, Data Modeling, and IndexingSystem Design
- Scalable Backend Architecture And Data ModelingSystem Design
- Scalable Service And Distributed System DesignSystem Design