Top 30 Http Interview Questions and Answers

30 questions. Pick an answer, or open “Show the answer” to read it.

Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.

1. Question 1 of 30

   In a bare http module server, what is the consequence of never calling res.end inside the request listener?

   • aThe client connection hangs because the response is never finalized
   • bNode automatically sends an empty 200 after a timeout
   • cThe request is silently retried by the http module
   • dThe server crashes with an unhandled exception
   Show the answer

   Answer: a · The client connection hangs because the response is never finalized

   res.end finalizes and flushes the response; without it the client waits indefinitely. Node does not auto-complete the response, crash, or retry the request on its own.

   Read the full bite: Minimal HTTP server with the http module

2. Question 2 of 30

   Which is the correct way to set a 201 Created status for a new resource created via a FastAPI POST endpoint?

   • a@app.post("/items/") async def create_item(name: str, status_code: int = 201):
   • b@app.post("/items/") async def create_item(name: str): return Response(status_code=201)
   • c@app.post("/items/", status_code=201)
   • d@app.post("/items/") async def create_item(name: str): raise HTTPException(status_code=201, detail="Resource created")
   Show the answer

   Answer: c · @app.post("/items/", status_code=201)

   The card explicitly states that the success status code should be set in the path operation decorator, as shown in option C, because it's part of the endpoint's contract. Option A is identified as a 'common footgun' for placing it in the function signature, and option D incorrectly uses HTTPException for a success code.

   Read the full bite: FastAPI: Set a Response's HTTP Status Code

3. Question 3 of 30

   Why must you wait for the request's end event before calling JSON.parse on a POST body?

   • aThe end event decrypts the body which is otherwise unreadable
   • breq.body is populated synchronously but only readable after end
   • cJSON.parse only works inside event handlers named end
   • dThe body arrives as multiple chunks and is only complete once end fires
   Show the answer

   Answer: d · The body arrives as multiple chunks and is only complete once end fires

   The request is a stream delivering chunks via data events; the full body exists only after end. The body is not encrypted, JSON.parse works anywhere, and req.body is not natively populated.

   Read the full bite: Reading a POST body from the request stream

4. Question 4 of 30

   Which approach correctly handles the full response lifecycle when fetching JSON from a REST API in production using Python's requests?

   • aSet a request timeout but skip status checks to parse faster
   • bUse r.text and manually split the string to extract JSON fields
   • cVerify the status with r.raise_for_status() before parsing with r.json()
   • dPass query parameters in the request body and call r.json() directly
   Show the answer

   Answer: c · Verify the status with r.raise_for_status() before parsing with r.json()

   Calling r.raise_for_status() before r.json() catches HTTP errors like 404 or 500 before parsing fails. Skipping the status check is a major red flag because error responses often do not contain valid JSON, causing r.json() to crash.

   Read the full bite: How do you fetch JSON from a REST API and parse it?

5. Question 5 of 30

   Why does enabling keepAlive on an http.Agent improve performance for repeated requests to the same host?

   • aIt runs each request on a separate CPU core
   • bIt compresses request bodies to reduce bandwidth
   • cIt reuses pooled sockets, skipping the TCP and TLS handshakes on later requests
   • dIt caches response bodies so repeated requests return instantly
   Show the answer

   Answer: c · It reuses pooled sockets, skipping the TCP and TLS handshakes on later requests

   keepAlive keeps sockets in the pool for reuse, avoiding repeated handshakes that add round trips. It does not compress, parallelize across cores, or cache responses.

   Read the full bite: http.Agent and connection pooling

6. Question 6 of 30

   In a minimal Express app, what does omitting the app.listen call result in?

   • aThe server never binds to a port, so no requests are served
   • bExpress throws an error at startup demanding a port
   • cRoutes respond but on a random default port
   • dThe app serves only the root route and ignores others
   Show the answer

   Answer: a · The server never binds to a port, so no requests are served

   app.listen binds the server to a port; without it nothing accepts connections. Express does not pick a random port, throw automatically, or selectively serve routes.

   Read the full bite: Minimal Express Hello World server

7. Question 7 of 30

   When consuming a REST API, what is the primary function of the HTTP status code in the server's response?

   • aTo inform the client about the outcome of its request, such as success or failure.
   • bTo identify the specific resource (e.g., a user's profile) that the client was trying to access.
   • cTo specify the type of data format (e.g., JSON, XML) contained in the response body.
   • dTo provide additional metadata or authentication tokens for subsequent requests.
   Show the answer

   Answer: a · To inform the client about the outcome of its request, such as success or failure.

   The card explains that the HTTP status code is "the waiter telling you if your order succeeded," directly indicating its role in communicating the success or failure of the request. Other options describe functions handled by HTTP headers or the URL.

   Read the full bite: Consuming REST APIs: Speaking to Web Services

8. Question 8 of 30

   When returning data from a JSON API, why is res.json preferred over res.end for sending an object?

   • ares.end is deprecated and will be removed from Express
   • bres.json is faster because it skips serialization
   • cres.end cannot finalize a response without a status code
   • dres.json serializes the object and sets application/json, while res.end does neither
   Show the answer

   Answer: d · res.json serializes the object and sets application/json, while res.end does neither

   res.json stringifies the object and sets the JSON content type; res.end sends raw data with no serialization or content-type help. res.end is not deprecated, and res.json does serialize rather than skip it.

   Read the full bite: res.send vs res.json vs res.end

9. Question 9 of 30

   Which action is crucial for a Node.js HTTP server to signal that a response has been fully sent to the client?

   • aCalling server.listen() to activate the server on a port.
   • bSetting the response.statusCode to a success code like 200.
   • cInvoking response.end() on the response object.
   • dUsing response.write() to send all data chunks to the client.
   Show the answer

   Answer: c · Invoking response.end() on the response object.

   The card explicitly states that `response.end()` is critical to signal that the response is complete, otherwise the client will hang indefinitely. While `response.write()` sends data, it does not close the connection or mark the response as finished.

   Read the full bite: Creating a Basic HTTP Server in Node.js

10. Question 10 of 30

    Which scenario is least suitable for declaring individual HTTP headers using Header() in a FastAPI path operation?

    • aHandling a full OAuth2 authentication and authorization flow.
    • bAccessing a specific X-Request-ID for tracing a request.
    • cImplementing a simple API key check using an X-API-Key header.
    • dRetrieving a client's User-Agent for logging purposes.
    Show the answer

    Answer: a · Handling a full OAuth2 authentication and authorization flow.

    The card explicitly advises against using Header() for complex authentication schemes like OAuth2, as FastAPI provides dedicated security utilities for such cases. It is well-suited for simpler tasks like reading User-Agent, API keys, or tracing IDs.

    Read the full bite: Declaring Request Headers in FastAPI

11. Question 11 of 30

    In a standard client-side React Router setup versus a Next.js App Router application, what is the critical difference in HTTP semantics when a user visits an unmatched URL?

    • aReact Router's wildcard route automatically issues an HTTP 404 status for the initial document request, while Next.js not-found.js returns HTTP 200 by default.
    • bBoth routers handle unmatched routes client-side, but React Router requires manual layout wrapping while Next.js preserves shared layouts automatically through file-system conventions.
    • cReact Router relies on implicit file-system routing to discover 404 boundaries, while Next.js App Router requires explicit wildcard route definitions in a central configuration file.
    • dNext.js App Router renders not-found.js on the server and sends a true HTTP 404 status, whereas React Router's catch-all renders in the browser and typically preserves the server's original HTTP 200 response.
    Show the answer

    Answer: d · Next.js App Router renders not-found.js on the server and sends a true HTTP 404 status, whereas React Router's catch-all renders in the browser and typically preserves the server's original HTTP 200 response.

    Next.js App Router's not-found.js convention server-renders a true HTTP 404 response, while React Router's wildcard route only manipulates the DOM client-side and leaves the initial document's HTTP 200 status unchanged. Option A is tempting because it reflects the common misconception that a React Router catch-all route affects the HTTP status code, but the framework has no built-in server-side semantics for doing so.

    Read the full bite: How do you handle 404s in React Router and Next.js App Router?

12. Question 12 of 30

    In FastAPI, when you need to add a custom HTTP header like a trace ID to a JSON response without altering the response body, what is the correct method?

    • aReturn a fastapi.Response object directly, populating its content and headers.
    • bDeclare a Response parameter in the path operation, set headers on its .headers attribute, and return your data normally.
    • cInclude the custom header as a top-level key-value pair within the JSON data returned by the endpoint.
    • dDefine a custom HTTPResponse class that inherits from JSONResponse and overrides its headers attribute.
    Show the answer

    Answer: b · Declare a Response parameter in the path operation, set headers on its .headers attribute, and return your data normally.

    The card states to declare a Response parameter, set headers on its .headers attribute, and then return your data normally. Returning the Response object directly (option A) is explicitly warned against as a 'footgun' because FastAPI automatically merges the headers with your returned data.

    Read the full bite: FastAPI: Setting Custom Response Headers

13. Question 13 of 30

    When using fetch, how can you ensure both network failures and HTTP 404 errors are handled by the same catch block?

    • aAttach a second catch block right after fetch to capture 4xx and 5xx status codes
    • bCheck response.ok in the then handler and throw an error if false, before parsing the body
    • cImmediately call response.json() and throw if the parsed result lacks expected data fields
    • dCheck if response.status equals 200 and throw if not, then return response.json()
    Show the answer

    Answer: b · Check response.ok in the then handler and throw an error if false, before parsing the body

    fetch resolves for HTTP error statuses, so you must inspect response.ok and throw manually to reach the catch block. A second catch block is ineffective because 4xx and 5xx responses do not trigger rejection.

    Read the full bite: How would you modify fetch to handle HTTP error statuses?

14. Question 14 of 30

    When configuring fetch inside an async createUser function to POST JSON data, which option correctly serializes the payload and handles the response?

    • abody is JSON.stringify(data), Content-Type is application/json, and it returns the raw Response object
    • bbody is JSON.stringify(data), Content-Type is application/json, it checks response.ok, and returns await response.json()
    • cbody is the raw data object, Content-Type is application/json, and it returns await response.json()
    • dbody is JSON.stringify(data), the Content-Type header is omitted, and it returns await response.json()
    Show the answer

    Answer: b · body is JSON.stringify(data), Content-Type is application/json, it checks response.ok, and returns await response.json()

    Option B is correct because fetch requires JSON.stringify to serialize the payload and a Content-Type header so the server can parse it, plus it returns the parsed JSON rather than the raw Response. Option C is tempting but wrong because passing the raw object directly causes the body to become the string [object Object], silently breaking the request.

    Read the full bite: Write a createUser function that POSTs JSON via fetch

15. Question 15 of 30

    What is a critical pitfall to avoid when using the `res` object in an Express route handler?

    • aTrying to access client-sent data using `res.body` instead of `req.body`.
    • bSending multiple HTTP responses for a single client request.
    • cUsing `res.send()` to return a JavaScript object directly without stringifying it.
    • dForgetting to include `req` as the first parameter in the handler function.
    Show the answer

    Answer: b · Sending multiple HTTP responses for a single client request.

    The card explicitly warns against sending more than one response per request, as it closes the connection and leads to errors. While other options describe common mistakes, they are either syntax issues, misunderstandings of object roles, or not critical errors in the same way.

    Read the full bite: Express Request and Response Objects (req, res)

16. Question 16 of 30

    What is the main advantage of using the FormData API when submitting an HTML form via JavaScript?

    • aIt allows form submissions to occur without requiring a full page reload.
    • bIt provides built-in client-side validation for all form input fields.
    • cIt ensures that all form data is securely encrypted before being sent to the server.
    • dIt automatically handles the correct encoding and Content-Type header for complex data, including file uploads.
    Show the answer

    Answer: d · It automatically handles the correct encoding and Content-Type header for complex data, including file uploads.

    The FormData API was created to automate the tedious and error-prone process of collecting, encoding (especially multipart/form-data for files), and setting the correct Content-Type headers for AJAX form submissions. While it is often used with asynchronous requests that prevent page reloads, FormData itself doesn't enable the no-reload aspect; it simplifies the data preparation for such requests.

    Read the full bite: FormData: Package Form Data for HTTP Requests

17. Question 17 of 30

    A React app on https://app.example.com sends a cross-origin POST to https://api.other.com/events with Content-Type application/json and an Authorization header. Why does the browser first send an OPTIONS request?

    • aThe server requires authentication and must verify the token before accepting the POST.
    • bThe combination of application/json Content-Type and the Authorization header makes it a complex cross-origin request.
    • cPOST requests with a request body always trigger a CORS preflight regardless of headers used.
    • dIncluding credentials in a cross-origin request always forces the browser to perform a preflight check.
    Show the answer

    Answer: b · The combination of application/json Content-Type and the Authorization header makes it a complex cross-origin request.

    The correct answer reflects that application/json is not a CORS-safelisted Content-Type and Authorization is a custom header, so the browser must preflight the complex cross-origin request. The most tempting distractor incorrectly suggests the server initiates the OPTIONS call to verify auth, whereas the card states the browser, not the server, enforces CORS by sending the preflight.

    Read the full bite: When does fetch trigger a CORS preflight, and what POST is complex?

18. Question 18 of 30

    Which statement accurately describes the proper way to parse a JSON list from an HTTP GET response in Dart?

    • aAwait http.get with a Uri, immediately decode response.body into a List<dynamic>, and cast each element to Map<String, dynamic> inside a loop
    • bCall http.get inside a synchronous function, check statusCode, and use jsonDecode with dynamic typing to avoid casting errors
    • cPass the endpoint string directly to http.get, await the result, and call jsonDecode(response.body) as List<Map<String, dynamic>> without checking statusCode
    • dConstruct a Uri with Uri.parse, await http.get, check that statusCode equals 200, then decode and cast the body to List<Map<String, dynamic>>
    Show the answer

    Answer: d · Construct a Uri with Uri.parse, await http.get, check that statusCode equals 200, then decode and cast the body to List<Map<String, dynamic>>

    Option D is correct because package:http requires a Uri, verifying statusCode 200 prevents decoding error pages, and casting to List<Map<String, dynamic>> gives the compiler the concrete collection shape. Option C is tempting because it includes the right cast, but passing a raw string is invalid and skipping the status check risks decoding a non-JSON error response.

    Read the full bite: Make a GET request with http and parse JSON in Dart

19. Question 19 of 30

    Which approach correctly implements an AsyncValidatorFn that performs an HTTP username check while minimizing backend load and preventing race conditions?

    • aReturn an Observable that uses debounceTime and switchMap, letting Angular set PENDING and bind control.pending in the template
    • bSubscribe to the HTTP call inside the validator, call markAsPending on the control, and update a component property to show the loading state
    • cReturn the HTTP Observable directly without debounceTime so every keystroke triggers an immediate, cancelable request
    • dReturn a Promise from the HTTP call and manually set the control to PENDING with markAsPending until it resolves
    Show the answer

    Answer: a · Return an Observable that uses debounceTime and switchMap, letting Angular set PENDING and bind control.pending in the template

    Returning a debounced Observable with switchMap allows Angular to automatically manage the PENDING status, unsubscribe from prior in-flight requests when the value changes, and avoid memory leaks. Option B breaks cancellation by subscribing internally and wrongly manages state imperatively, while C uses an uncancelable Promise and manual pending, and D floods the backend by skipping debounce.

    Read the full bite: Implement an async Angular validator with HTTP and PENDING feedback

20. Question 20 of 30

    Which scenario is most likely to cause a functional issue immediately after adding app.use(helmet()) to an Express app without further configuration?

    • aThe application implements custom authentication logic.
    • bThe application is running in a local development environment without HTTPS.
    • cThe application handles sensitive user data.
    • dThe application loads scripts or styles from external domains like CDNs.
    Show the answer

    Answer: d · The application loads scripts or styles from external domains like CDNs.

    The default Content-Security-Policy (CSP) in Helmet is very strict, only allowing resources from the same origin ('self'). This will block common external resources like scripts from CDNs or Google Fonts, causing functional issues until the CSP is explicitly configured. While running without HTTPS can cause issues with 'upgrade-insecure-requests', the card highlights CSP configuration for external resources as the primary and most common 'footgun'.

    Read the full bite: Helmet.js: Secure Express Apps with HTTP Headers

21. Question 21 of 30

    What is a key advantage of using Axios for HTTP requests compared to the native fetch API?

    • aIt automatically handles all network connection issues without requiring error handling code.
    • bIt is exclusively designed for server-side Node.js applications, unlike fetch.
    • cIt consistently rejects Promises for HTTP error status codes like 404 or 500.
    • dIt offers a synchronous API, simplifying data retrieval without async/await.
    Show the answer

    Answer: c · It consistently rejects Promises for HTTP error status codes like 404 or 500.

    The card explicitly states that 'fetch doesn't automatically reject on HTTP error codes like 404 or 500,' whereas Axios provides 'better error handling' by consistently rejecting in such scenarios. Other options misrepresent Axios's asynchronous nature, error handling scope, or environment compatibility.

    Read the full bite: Axios: A Simpler Way to Make HTTP Requests

22. Question 22 of 30

    When sending a JavaScript object as JSON data in a POST request using fetch and RequestInit, what is a crucial configuration step?

    • aSpecifying the 'Content-Type' header as 'application/json'.
    • bOmitting the 'body' property, as fetch infers it from the method.
    • cSetting the 'method' property to 'GET' to ensure data is sent.
    • dAutomatically converting the JavaScript object to a JSON string within RequestInit.
    Show the answer

    Answer: a · Specifying the 'Content-Type' header as 'application/json'.

    The card explicitly states that a common pitfall is sending a JSON body without setting the 'Content-Type' header to 'application/json', which is crucial for the server to correctly interpret the data. Option D is incorrect because RequestInit itself does not perform JSON stringification; you must use JSON.stringify() explicitly for the 'body' property.

    Read the full bite: Configuring Fetch Requests with `RequestInit`

23. Question 23 of 30

    Which of the following correctly describes a required step when wiring Retrofit to fetch a post by ID?

    • aThe API endpoint interface must be annotated with @GET and use @Query to bind the ID parameter to the URL path
    • bThe Retrofit builder must include addConverterFactory so JSON can be deserialized into your data class
    • cThe service interface should be implemented manually as a concrete class that extends Retrofit.Callback
    • dThe @GET annotation must include the complete URL including the domain and the ID placeholder
    Show the answer

    Answer: b · The Retrofit builder must include addConverterFactory so JSON can be deserialized into your data class

    Retrofit cannot parse JSON automatically without an explicit converter factory such as GsonConverterFactory, so omitting it causes a runtime exception. The most tempting distractor confuses @Query with @Path: @Query would append ?id=42 instead of substituting the path segment /posts/42.

    Read the full bite: How would you use Retrofit to GET /posts/{id} and key components?

24. Question 24 of 30

    What is the primary benefit of using the Headers object when working with HTTP headers in web applications?

    • aIt ensures header names are always converted to uppercase for consistency across all requests.
    • bIt provides a standardized way to encrypt header values for secure data transmission.
    • cIt enables direct access and modification of raw HTTP header strings for advanced use cases.
    • dIt automatically enforces HTTP header formatting rules, such as case-insensitivity and preventing forbidden headers.
    Show the answer

    Answer: d · It automatically enforces HTTP header formatting rules, such as case-insensitivity and preventing forbidden headers.

    The Headers object's main advantage is its automatic handling of HTTP header rules, including case-insensitivity and preventing forbidden headers, as stated in the card. It abstracts away raw string manipulation for safety, rather than enabling it, and does not handle encryption or enforce uppercase conversion.

    Read the full bite: The Headers Object: A Safer Way to Manage HTTP Headers

25. Question 25 of 30

    Your POST /login handler reads req.body but it is always undefined. What is the most likely cause?

    • aYou forgot to await req.body
    • bExpress does not support req.body for login routes
    • cThe express.json body-parsing middleware is not mounted
    • dThe route uses GET instead of POST internally
    Show the answer

    Answer: c · The express.json body-parsing middleware is not mounted

    req.body is populated only when a body-parsing middleware like express.json runs first; without it req.body stays undefined. req.body is synchronous, so awaiting it would not help.

    Read the full bite: Basic presence validation on a POST login route

26. Question 26 of 30

    What is the primary benefit URLSearchParams offers to web developers?

    • aIt provides a standardized and safe way to handle URL query strings, including encoding and decoding.
    • bIt automatically validates the structure of all URL components, not just query parameters.
    • cIt allows for the secure storage of user authentication tokens within the URL.
    • dIt enables client-side routing and navigation without requiring full page reloads.
    Show the answer

    Answer: a · It provides a standardized and safe way to handle URL query strings, including encoding and decoding.

    The card states URLSearchParams provides a "standardized, safe, and convenient way to handle this common task" of parsing and building query strings, and that "It handles all the tricky encoding and formatting details for you." Option C is incorrect because storing sensitive data like authentication tokens directly in the URL is generally insecure, even with URLSearchParams. While URLSearchParams can be used with the History API for client-side routing (Option D), it does not enable routing itself; it only manages the query part of the URL. Option B is incorrect as it explicitly states not to use it for other URL components like path or hash fragment.

    Read the full bite: URLSearchParams: Safely Build and Parse URL Queries

27. Question 27 of 30

    Why attach a statusCode and isOperational flag to custom Error subclasses?

    • aTo bypass the need for an error-handling middleware
    • bTo let the centralized handler choose the HTTP code and decide whether the error is safe to expose
    • cTo make the errors throw faster
    • dTo automatically retry the failed request
    Show the answer

    Answer: b · To let the centralized handler choose the HTTP code and decide whether the error is safe to expose

    Carrying statusCode lets one central handler map the error to the right HTTP response, and isOperational signals whether it is an expected, client-safe error versus an unexpected bug. It neither speeds throwing nor replaces the middleware.

    Read the full bite: Custom Error classes and centralized handling

28. Question 28 of 30

    When using Angular's HttpClient, what action is necessary to initiate the actual network request to the server?

    • aCalling an HTTP method like http.get() or http.post()
    • bInjecting the HttpClient service into your component or service
    • cSubscribing to the Observable returned by an HttpClient method
    • dSpecifying the expected response type using a generic, e.g., http.get<DataType>()
    Show the answer

    Answer: c · Subscribing to the Observable returned by an HttpClient method

    The card explicitly states that 'The HTTP request is only dispatched when you call .subscribe() on that Observable.' Calling methods like http.get() merely returns a 'cold' Observable, which does not send the request until subscribed to.

    Read the full bite: Angular HttpClient: Your App's API Connector

29. Question 29 of 30

    When a server receives an API request where the client has omitted a mandatory piece of information in the request body, which HTTP status code class is most appropriate for the server to return?

    • a2xx, because the server successfully processed the request's receipt.
    • b5xx, because the server was unable to fulfill the request due to an error.
    • c4xx, as the client's request itself is flawed or incomplete.
    • d3xx, to guide the client to a different resource that might accept the incomplete request.
    Show the answer

    Answer: c · 4xx, as the client's request itself is flawed or incomplete.

    The card explains that 4xx codes indicate a client error, meaning the client made a mistake, such as sending a malformed request or missing required data. A 5xx code would signal a server-side issue, which is not the case when the client's input is incorrect.

    Read the full bite: HTTP Status Codes: The Server's Signal

30. Question 30 of 30

    When handling a Request object in a service worker, why is it often necessary to call request.clone() before using it in multiple operations?

    • aTo ensure that the request's body stream can be read independently by each operation.
    • bTo allow modification of the request's URL or headers for different operations.
    • cTo prevent the original Request object from being garbage collected after its first use.
    • dTo create a deep copy of the request, including its associated response, for caching purposes.
    Show the answer

    Answer: a · To ensure that the request's body stream can be read independently by each operation.

    The Request object's body is a ReadableStream that can only be consumed once. Cloning creates a new Request object with an independent, unread copy of the body stream, allowing it to be used by multiple consumers like caches.match() and fetch(). Option B is incorrect because Request objects are immutable; cloning does not allow modification of properties like URL or headers.

    Read the full bite: The Fetch API's Request Object