HTTP and REST Error Handling Basics Quiz Quiz

Test your knowledge of HTTP and REST error handling, including common status codes, retry strategies, backoff techniques, and idempotency. This quiz covers essential concepts for reliably managing API errors using industry-standard practices.

1. Identifying HTTP Success

   Which status code indicates a successful HTTP request with a response body, such as when retrieving data from a REST API?

   1. 301 Moved Permanently
   2. 500 Internal Server Error
   3. 200 OK
   4. 404 Not Found

   Explanation: 200 OK is used when the request has succeeded and the server returns the requested data, making it the standard code for successful GET requests. 301 Moved Permanently means the resource has been moved and typically relates to redirection, not success with data returned. 404 Not Found shows that the resource does not exist. 500 Internal Server Error indicates a server-side problem, not successful completion.

2. Client Error Example

   What does the HTTP status code 400 Bad Request indicate when returned by a RESTful server?

   1. The client sent an invalid request
   2. The requested resource is unavailable
   3. Authentication is required
   4. The request was successful

   Explanation: A 400 Bad Request status means the client made a request that could not be understood by the server, possibly due to malformed syntax or invalid data. 'The requested resource is unavailable' better fits a 404 or 503 response. 'Authentication is required' would correspond to a 401 code. 'The request was successful' fits 200 OK, not 400.

3. Server Error Response

   You send a correct request, but the server returns 500 Internal Server Error. What does this status code mean?

   1. The client syntax is incorrect
   2. The resource has been permanently moved
   3. There is an error on the server side
   4. The request is unauthorized

   Explanation: 500 Internal Server Error means an unexpected condition occurred on the server, not caused by the client's request. Unauthorized requests would return 401, not 500. 'The resource has been permanently moved' refers to 301. 'The client syntax is incorrect' would be 400, not 500.

4. Handling Rate Limiting

   When a REST API returns HTTP 429 Too Many Requests, what is it signaling to the client?

   1. The server cannot find the requested resource
   2. The client has sent too many requests in a short period
   3. The resource has been successfully deleted
   4. The request was forbidden due to authentication failure

   Explanation: 429 Too Many Requests indicates that the client is being rate-limited due to excessive requests. 404 Not Found is applicable when the resource cannot be found. 403 Forbidden refers to failed authentication or authorization. 204 No Content is a common response for a successful deletion, not 429.

5. Understanding Idempotency

   If you retry an HTTP PUT request and get the same result each time without unintended side effects, which property describes this behavior?

   1. Latency
   2. Idempotency
   3. Caching
   4. Compliance

   Explanation: Idempotency means making the same call multiple times produces the same effect, which is true for PUT in REST when designed correctly. Latency is the time taken by a request, not about repeatable outcomes. Caching deals with saving responses temporarily. Compliance relates to following protocols or standards.

6. Choosing Retry Strategy

   What is an appropriate strategy when handling HTTP 503 Service Unavailable errors in a client application?

   1. Resend the request without modification every time
   2. Send repeated requests in quick succession
   3. Retry with exponential backoff
   4. Immediately switch to using GET requests

   Explanation: Retrying with exponential backoff helps avoid overwhelming the server during temporary outages represented by 503. Switching HTTP methods, such as switching to GET, is not appropriate. Sending repeated requests quickly can make the problem worse. Resending the request immediately every time may lead to hitting rate limits and is inefficient.

7. Safe HTTP Methods

   Which HTTP method is considered idempotent and safe for retrieving data without modifying resources in RESTful services?

   1. GET
   2. TRACE
   3. POST
   4. CONNECT

   Explanation: GET requests are both idempotent and safe, as they retrieve data without causing side effects. POST is not idempotent because it often creates new resources. CONNECT and TRACE are special-purpose methods, not typically used for safe data retrieval.

8. Unexpected Client Error

   After making a POST request, the server returns HTTP 409 Conflict. What does this usually mean?

   1. The server timed out waiting for the request
   2. The server did not understand the request
   3. There is a conflict with the current state of the target resource
   4. The request requires user authentication

   Explanation: HTTP 409 Conflict signals a problem such as a duplicate entry or conflicting changes to a resource, which prevents request completion. Not understanding the request fits a 400 error. Requiring authentication would return 401, while timeout issues would return 408.

9. Rate Limit Header Use

   What should a client application do when it receives an HTTP 429 response with a Retry-After header?

   1. Instantly retry the request without delay
   2. Switch to a PUT request method
   3. Wait the specified time before sending another request
   4. Assume the API resource no longer exists

   Explanation: The Retry-After header tells the client how long to wait before retrying, which helps prevent further rate-limiting. Instantly retrying ignores the header, potentially worsening rate limits. Switching to PUT is not related, and assuming the resource doesn’t exist confuses 429 with 404.

10. Error Handling for Non-Idempotent Methods

    Why should clients be cautious when retrying failed POST requests?

    1. POST requests are ignored by most RESTful servers
    2. POST requests are not idempotent, so repeating them may create duplicate resources
    3. POST requests always return 200 OK regardless of outcome
    4. POST requests delete resources on the server

    Explanation: If a POST request is retried, the server may process the creation twice resulting in duplicated resources because POST is not idempotent. POST may return various status codes, not just 200 OK. It is used primarily to create, not delete resources. RESTful servers do process POST requests.

11. Common Status Code for Missing Resources

    When making a GET request to a REST API endpoint that does not exist, which HTTP status code is commonly returned?

    1. 302 Found
    2. 202 Accepted
    3. 201 Created
    4. 404 Not Found

    Explanation: 404 Not Found indicates that the requested resource does not exist at the specified endpoint. 202 Accepted indicates the request was received but not yet processed. 302 Found means a temporary redirect. 201 Created is for successful creation, not missing resources.

12. Idempotency Key Purpose

    Why might a client include an idempotency key in a REST API POST request?

    1. To switch the request method from POST to GET automatically
    2. To encrypt sensitive data in the request
    3. To cache the response for quicker access
    4. To prevent duplicate processing if the request is retried

    Explanation: An idempotency key allows the server to recognize duplicate POST requests due to retries and avoid repeating the operation. Caching, switching methods, and encrypting data are unrelated to idempotency keys. Idempotency helps make POST operations safer when retries are required.

13. Permanent Redirect Status Code

    Which HTTP status code indicates that a resource has been permanently moved to a new location in a RESTful API?

    1. 402 Payment Required
    2. 301 Moved Permanently
    3. 204 No Content
    4. 401 Unauthorized

    Explanation: 301 Moved Permanently means the resource is now found at a different URL, and clients should update bookmarks or links. 401 shows authentication failure. 204 means successful request with no content returned. 402 is reserved for future use and not standardly employed.

14. Purpose of Exponential Backoff

    What is the main advantage of using exponential backoff when retrying failed HTTP requests?

    1. It returns a 403 status code to the client
    2. It returns cached responses to the client
    3. It guarantees immediate success on retry
    4. It reduces the likelihood of overloading the server

    Explanation: Exponential backoff spaces out retries progressively, lowering load on the server and giving it time to recover. Status codes like 403 are unrelated to backoff strategy. Immediate success cannot be guaranteed by retry strategies, and returning cached responses is a different concern.

15. Detecting Unauthorized Request

    While calling an API endpoint, a client receives an HTTP 401 Unauthorized response. What does this mean?

    1. The method used is not allowed for this resource
    2. The client must provide valid authentication credentials
    3. The request contained invalid data formatting
    4. The resource has been deleted from the server

    Explanation: 401 Unauthorized indicates that the request lacks valid authentication information. Deleted resources would result in 404 or 410. Invalid data formatting would lead to a 400 Bad Request. If the method was not allowed, the response would be 405 Method Not Allowed.

16. Safe Retry of Idempotent Requests

    Why is it generally safe for clients to retry failed GET requests compared to POST requests?

    1. GET methods always return JSON
    2. GET methods are idempotent and should not modify data
    3. POST methods require no response body
    4. POST methods are limited to updating data only

    Explanation: GET requests are idempotent and safe, as repeating them does not change server data. GET can return any kind of content, not just JSON. POST is commonly used to create resources, not just for updating. Both methods can include response bodies.