RESTful API And HTTP Service Design

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 single recv() contains the full request; read until \r\n\r\n, then use Content-Length for the body.

• Status codes are part of the API contract. Use 200 OK for successful reads, 201 Created with Location for new resources, 204 No Content for successful deletes, 400 Bad Request for malformed input, 404 Not Found, 409 Conflict, 415 Unsupported Media Type, and 500 Internal Server Error.

• RESTful resource modeling should use nouns and stable identifiers: /questions, /questions/{id}, /questions/{id}/answers. Use GET for reads, POST for creation, PATCH or PUT for updates, and DELETE for removal; avoid RPC-style paths like /createQuestion.

• Idempotency distinguishes safe retries from duplicate writes. GET, PUT, and DELETE should be idempotent; POST generally is not unless you add an Idempotency-Key pattern. 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 fragile if 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 limit and offset is simple but degrades for large offsets; cursor pagination using (created_at, id) is more stable. Cap limit, for example min(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, or epoll. 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. SQLite is a strong next step for local durability; Postgres fits 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 as p95 and p99; 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.