Designing RESTful Endpoints Quiz Quiz

Assess your understanding of best practices for designing RESTful API endpoints. Explore topics such as proper HTTP methods, resource naming conventions, idempotency, and versioning to build scalable and maintainable APIs.

1. Choosing HTTP Methods for Resource Updates

   Which HTTP method should be used to fully replace the data of an existing resource, like updating all fields of a user profile at endpoint /users/123?

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

   Explanation: PUT is the correct choice for completely replacing an existing resource with new data, making it idempotent when the same request is repeated. POST is intended for creating new resources or triggering server-side actions, not full replacements. PATCH is suited for partial updates, not total replacements. FETCH is not a standard HTTP method for RESTful APIs.

2. Resource Naming in RESTful Endpoints

   In RESTful API design, which is the preferred way to name an endpoint for accessing a list of orders?

   1. /orders
   2. /ordersList
   3. /order_list
   4. /getOrders

   Explanation: /orders uses a plural noun to represent a collection of resources and aligns with RESTful naming conventions. /getOrders includes an action in the path, which is discouraged as RESTful design uses HTTP methods, not verbs in endpoint paths. /order_list and /ordersList break the convention of plural nouns and introduce unnecessary complexity.

3. Ensuring Idempotency in Delete Operations

   Which characteristic must a DELETE endpoint have to be considered idempotent in RESTful services?

   1. A DELETE endpoint should always return HTTP 201
   2. Each DELETE request removes a different resource
   3. Multiple identical DELETE requests should have the same overall effect as one
   4. DELETE always restores a resource if called twice

   Explanation: An idempotent DELETE operation means that making the same request multiple times achieves the same result and does not alter the state after the first successful deletion. Removing a different resource on each call breaks idempotency. DELETE cannot restore resources, so the third option is incorrect. HTTP 201 is used for creation, not standard with DELETE requests.

4. Incorporating Versioning into RESTful APIs

   Given a need to support multiple versions of an API, which is a commonly accepted approach to indicate versioning in RESTful endpoints?

   1. Placing the version in the HTTP body
   2. Using a prefix like /api/ before every resource
   3. Naming each endpoint with a version suffix (e.g., /productsV1)
   4. Adding a version number to the URL path (e.g., /v1/products)

   Explanation: Versioning in the URL path, such as /v1/products, is a widely accepted and visible method for clients. Placing a version number in the HTTP body is not practical since the routing happens before the body is parsed. Adding a version suffix to every endpoint is not standard and can cause confusion. Using an /api/ prefix may organize endpoints, but does not communicate version information.

5. Nested Resource Endpoint Structure

   Which of the following represents a proper endpoint structure for accessing comments related to a specific post in RESTful APIs?

   1. /posts/456/comments
   2. /commentsofpost456
   3. /posts/comments/456
   4. /comments?postId=456

   Explanation: /posts/456/comments clearly shows comments as a sub-resource of a specific post using intuitive hierarchical path structure. While using query parameters like in /comments?postId=456 can work, it is less expressive in endpoint hierarchy. /posts/comments/456 misplaces the placement of the parent and child resource, and /commentsofpost456 is neither descriptive nor follows naming conventions.