API Design Essentials Quiz: Resources, Validation, Versioning, and Idempotency Quiz

Test your knowledge of API design best practices, including resource modeling, request validation, versioning strategies, and idempotency. This quiz covers fundamental API concepts to help you build robust, user-friendly web services.

1. Resource Identification

   Which URL format best represents a RESTful resource for an individual user with an ID of 42?

   1. /users/42
   2. /users?id=42
   3. /getUser?id=42
   4. /user/42/details

   Explanation: The correct answer is /users/42, which clearly and concisely identifies a resource in RESTful API design. /getUser?id=42 and /users?id=42 use query parameters or action words, which are less RESTful. /user/42/details adds unnecessary detail to the path, making it less standard for retrieving a single user resource.

2. HTTP Methods and Idempotency

   Which HTTP method is designed to be idempotent, meaning making the same request multiple times will have the same effect as once?

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

   Explanation: PUT is idempotent, as sending the same data to a resource multiple times does not change its state beyond the first request. POST is not idempotent because it typically creates new resources; repeated POSTs may generate duplicates. CONNECT and TRACE are unrelated to resource modification and are rarely used in standard API design.

3. Input Validation Purpose

   Why is input validation important when designing an API that accepts user data?

   1. It guarantees faster API responses regardless of data.
   2. It makes the API impossible to hack.
   3. It automatically translates input into all languages.
   4. It prevents invalid or harmful data from entering the system.

   Explanation: Input validation ensures only expected and correct data is processed, reducing the risk of errors or security flaws. Validation does not guarantee faster responses, cannot make the API entirely hack-proof, and does not perform language translation. Some options suggest unrealistic or incorrect outcomes.

4. Resource Naming Pluralization

   According to API resource naming best practices, how should a collection of products be represented in the URI?

   1. /product
   2. /listproducts
   3. /productsList
   4. /products

   Explanation: The plural noun '/products' correctly designates a collection of resources, which matches widely-accepted conventions. Using '/product' is typically for a single item. '/listproducts' and '/productsList' introduce verbs or unnecessary descriptors not standard in resource naming.

5. HTTP Status Codes for Validation

   If an API request contains invalid input data, which HTTP status code should be returned?

   1. 400 Bad Request
   2. 201 Created
   3. 204 No Content
   4. 301 Moved Permanently

   Explanation: 400 Bad Request indicates the server cannot or will not process the request due to user error, such as invalid input. 201 Created is for successful creation of resources, not failed requests. 301 Moved Permanently suggests a redirect, while 204 No Content implies a successful operation with no data returned.

6. API Versioning in URIs

   Which of the following is a common and clear way to indicate API versioning within the URI?

   1. /v1/orders
   2. /orders?versioning=1
   3. /orders/version:1
   4. /orders/vOne

   Explanation: Including the version as a prefix, such as '/v1/orders', is a widely-used and well-understood API versioning strategy. '/orders/vOne' uses a non-standard format, '/orders/version:1' is less conventional, and query parameters like '/orders?versioning=1' are usually not dedicated for major versioning.

7. Idempotency Key Use Case

   When should an API client include an idempotency key in a request?

   1. When requesting static resources
   2. For all HEAD requests
   3. For simple GET queries with no change
   4. When retrying a POST request to avoid duplicate operations

   Explanation: Idempotency keys are most important for POST requests that create or change resources, especially in scenarios like retries, to ensure no duplicate actions occur. Static resources don't modify data, so idempotency isn’t needed. GET and HEAD requests are already idempotent by definition.

8. Self-Descriptive Messages

   In well-designed APIs, why should requests and responses be self-descriptive?

   1. To reduce backend code complexity and help clients understand data without extra documentation
   2. To increase server memory requirements
   3. To limit the number of supported HTTP methods
   4. To make APIs less secure

   Explanation: Self-descriptive operations allow clients to understand what an API expects and returns, improving usability and reducing developer reliance on external references. Increasing server memory and limiting HTTP methods are unrelated, while security is not weakened by self-description.

9. Consistent Data Validation Errors

   What should an API do when a client sends a request with multiple invalid fields?

   1. Only report the very first error
   2. Ignore invalid fields and process the rest
   3. Return a single response listing all validation errors with helpful messages
   4. Restart the request automatically

   Explanation: Good APIs report all detected validation errors in one response to help clients fix issues efficiently. Reporting only the first error is less user-friendly, ignoring errors can compromise data, and restarting the request is outside standard API behavior.

10. Resource Filtering

    How should an API allow clients to filter a list of resources, such as filtering books by author?

    1. By adding a filter action word to the URL, like /books/filter/Alice
    2. By using query parameters, like /books?author=Alice
    3. By putting the filter value in the HTTP body of GET requests
    4. By requiring a new endpoint for each author

    Explanation: Query parameters are the standard way to filter or search resource collections in APIs. Attaching filter actions to the path or requiring new endpoints is inefficient and against REST principles. GET requests should not use an HTTP body, so that option is invalid.

11. Statelessness Principle

    Why is the principle of statelessness important in API design?

    1. It requires every API to use authentication.
    2. It limits the number of supported endpoints.
    3. It ensures that each request contains all information needed for processing without relying on server context.
    4. It allows the server to save previous requests in memory indefinitely.

    Explanation: Statelessness mandates that requests are self-contained, making APIs scalable and easier to maintain. Saving previous requests in memory contradicts this principle, while the number of endpoints and authentication are unrelated to statelessness.

12. Error Response Structure

    Which is a good practice for error response structure in modern APIs?

    1. Hiding all error details from the client
    2. Responding with a plain 'Error' string and no HTTP status code
    3. Returning a JSON body with an error code and message
    4. Using binary data as the error response

    Explanation: A structured JSON error with code and message is clear for clients to parse and act upon. Plain strings without proper status codes lack context, hiding all error details hinders debugging, and binary data is unreadable in most client contexts.

13. URI Versioning Alternatives

    Which is NOT a recommended alternative to URI versioning for APIs?

    1. Using custom request headers to specify the version
    2. Including the version in the 'Accept' header (content negotiation)
    3. Using query parameters for versioning
    4. Randomly changing endpoints with every version

    Explanation: Randomizing endpoints breaks predictability and maintainability, making it unsuitable. Headers and query parameters are valid versioning alternatives; content negotiation via 'Accept' header is also widely used.

14. Resource Sub-Collection Example

    Which URI path correctly represents a sub-resource collection, such as all comments for a specific post with ID 7?

    1. /posts/7/comments
    2. /comments?post=7
    3. /comments/7/posts
    4. /posts/comments/7

    Explanation: The format /posts/7/comments shows a sub-collection owned by a parent resource, following REST conventions. Using query parameters is more appropriate for filtering but not sub-resource collections, while the other options do not represent proper parent-child relationships.

15. Safe HTTP Methods

    Which HTTP method is considered safe as it should not modify resources?

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

    Explanation: GET is defined as safe because it is intended only to retrieve data, not to alter any server resources. PATCH, DELETE, and POST may alter server data, so they are considered unsafe methods in terms of modification potential.

16. Idempotency Illustrated

    Which scenario best illustrates an idempotent API operation?

    1. Setting a user's email to 'a@example.com' using a PUT request multiple times
    2. Deleting multiple unrelated resources in one DELETE call
    3. Updating a comment using PATCH with different messages every time
    4. Creating a new order with the same POST request twice and getting two orders

    Explanation: Sending the same PUT request repeatedly with identical data results in the same resource state, demonstrating idempotency. Using POST to create resources can lead to duplication, which is not idempotent. PATCH with different data changes the resource each time, and deleting multiple items may have varying results depending on the resources' state.