HTTP u0026 REST Fundamentals Quiz: Methods, Status Codes, and OpenAPI Essentials Quiz

Test your knowledge of HTTP methods, REST principles, common status codes, idempotency, and pagination as described in OpenAPI specifications. Perfect for anyone looking to review the basics of building and documenting modern APIs using HTTP and RESTful standards.

  1. Identifying the Safe Method

    Which HTTP method is typically considered safe because it does not modify server state when used to fetch a list of resources, for example, retrieving users?

    1. GET
    2. POST
    3. PUT
    4. PATCH

    Explanation: GET is a safe HTTP method because it is used solely to retrieve data and should not have any side effects on the server. PUT and PATCH are used to modify existing resources, while POST is commonly used to create new resources, all of which can change server state. GET, when used correctly, does not alter any data on the server and is therefore considered safe.

  2. Purpose of the 201 Status Code

    When a client sends a POST request to create a new resource, which HTTP status code should the server return to indicate successful creation?

    1. 404 Not Found
    2. 200 OK
    3. 204 No Content
    4. 201 Created

    Explanation: The 201 Created status code is used to confirm that a new resource has been successfully created as a result of a POST request. 200 OK indicates a generic successful response but does not specifically mean a resource was created. 204 No Content means the request was successful but there is no content to send, and 404 Not Found indicates the resource was not found, not created.

  3. Idempotent Method Selection

    Which HTTP method is idempotent, meaning repeated identical requests should produce the same result on the server each time, such as updating a resource to a given value?

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

    Explanation: PUT is idempotent because making the same PUT request multiple times will always result in the resource having the same value. POST is not idempotent because multiple requests may create multiple resources. CONNECT and TRACE are less commonly used and do not fit typical REST operations, making PUT the correct choice in this case.

  4. Successful GET Request Status

    If a client successfully retrieves resource data using a GET request, which HTTP status code should be returned by the server?

    1. 500 Internal Server Error
    2. 201 Created
    3. 400 Bad Request
    4. 200 OK

    Explanation: 200 OK is the standard response for successful HTTP requests like GET, indicating the server is returning the requested data. 201 Created is used for successful resource creation, 400 Bad Request signals a client error, and 500 Internal Server Error refers to failures on the server's side, not successful retrievals.

  5. HTTP Method for Partial Updates

    When a client wants to partially update only specific fields of a resource, such as updating just a user's email address, which HTTP method should be used?

    1. DELETE
    2. PATCH
    3. OPTIONS
    4. HEAD

    Explanation: PATCH is intended for partial updates, allowing clients to send only the data that needs changing. DELETE removes a resource, HEAD retrieves only headers, and OPTIONS describes communication options, so they do not suit the need for updating specific fields.

  6. REST Pagination Best Practice

    What is a common practice for implementing pagination in REST APIs, for example in a GET /items endpoint returning long lists?

    1. Returning all items at once
    2. Requiring the client to guess page sizes
    3. Using query parameters like page and limit
    4. Sending pagination info in request headers

    Explanation: Commonly, REST APIs use query parameters such as page and limit to let clients specify which page of results and how many items per page they want. Returning all items at once is inefficient for large datasets, putting pagination info only in headers is less discoverable, and requiring the client to guess isn’t user-friendly or practical.

  7. Status Code for Invalid Request

    If a client sends poorly structured data to an API, such as missing a required field in a POST request, which status code should the server respond with?

    1. 301 Moved Permanently
    2. 400 Bad Request
    3. 304 Not Modified
    4. 401 Unauthorized

    Explanation: 400 Bad Request indicates the server cannot process the request due to invalid syntax or missing required data. 401 Unauthorized is for authentication errors, 301 Moved Permanently is used for URL redirection, and 304 Not Modified signals that the requested resource has not changed, making them unsuitable for reporting client input errors.

  8. HEAD Request Purpose

    What does an HTTP HEAD request do when sent to a REST endpoint like /users/123?

    1. Returns only headers without a message body
    2. Deletes the specified user
    3. Lists available resources
    4. Partially updates the username

    Explanation: HEAD requests retrieve the response headers for a resource, omitting the body content. DELETE removes resources, PATCH (not listed but similar) would update them, and simply listing resources is done using GET, not HEAD.

  9. Status Code for Resource Not Found

    When a client requests a resource that does not exist, such as /products/9999, what is the correct HTTP status code?

    1. 404 Not Found
    2. 202 Accepted
    3. 307 Temporary Redirect
    4. 403 Forbidden

    Explanation: 404 Not Found tells the client that the requested resource cannot be found on the server. 403 Forbidden means the client lacks permission, 307 Temporary Redirect is for temporary location changes, and 202 Accepted indicates the request was received but not yet processed.

  10. Idempotency in OpenAPI Specs

    In OpenAPI specs, which property is often used to describe that a PUT operation on /items/{itemId} is idempotent?

    1. Content type
    2. The method type PUT
    3. The summary field
    4. Response description

    Explanation: Idempotency for API operations is typically implied by the HTTP method used; PUT is recognized as idempotent according to REST semantics, so documenting a PUT method shows this property. Fields like summary or response description give extra information but don’t specifically mark idempotency, and content type defines the data format, not the operation’s nature.