Intermediate REST APIs test (Intermediate)

Sample questions

5 sample questions from the Intermediate REST APIs test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which HTTP method is considered a safe method and should not be used for resource creation?

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

   Answer: C. GET

   GET is a safe method, which means it does not change the server state. It is commonly used for retrieving data, not for creating resources. Using GET for resource creation is a common mistake, as it violates the HTTP method semantics.

2. Which HTTP method is appropriate to use when fetching user details from an API without modifying any server state?

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

   Answer: D. GET

   The GET method is considered a safe method because it retrieves data without modifying the server state. This makes it suitable for scenarios like fetching user details without causing any changes on the server.

3. In a realistic project scenario, how should you document the purpose and usage of an API endpoint in the OpenAPI specification?

   1. Include the endpoint's implementation logic directly in the OpenAPI specification.
   2. Use the 'summary' field to document the endpoint's behavior and expected inputs.
   3. Use the 'description' field in the OpenAPI specification to provide a clear explanation of what the endpoint does and how it should be used.
   4. Add endpoint descriptions in the 'servers' section of the OpenAPI specification.

   Answer: C. Use the 'description' field in the OpenAPI specification to provide a clear explanation of what the endpoint does and how it should be used.

   The 'description' field in the OpenAPI specification is the appropriate place to document the purpose and usage of an endpoint. This helps developers understand how to interact with the API correctly. Other options may relate to different aspects of OpenAPI, but they are not directly relevant to describing an endpoint's functionality in a realistic project scenario.

4. Which OAuth2 flow is best suited for machine-to-machine communication where the client application needs to access an API directly without user interaction?

   1. Password grant flow
   2. Authorization code flow
   3. Implicit flow
   4. Client credentials flow

   Answer: D. Client credentials flow

   OAuth2 client credentials flow is designed for machine-to-machine communication and is typically used when a client application needs to access an API directly without user interaction. This contrasts with the authorization code flow, which involves user interaction and is used for web and mobile applications that need to access protected resources on behalf of a user. The client credentials flow is appropriate for scenarios where the client application itself is the resource owner, such as backend services or server-to-server communication.

5. Which statement correctly describes how vendor extensions are denoted in the OpenAPI 3.0 specification?

   1. The OpenAPI 3.0 specification does not support vendor extensions.
   2. The OpenAPI 3.0 specification uses the 'x-' prefix for vendor extensions.
   3. The OpenAPI 3.0 specification uses the '@' symbol for vendor extensions.
   4. The OpenAPI 3.0 specification uses the 'v-' prefix for vendor extensions.

   Answer: B. The OpenAPI 3.0 specification uses the 'x-' prefix for vendor extensions.

   In OpenAPI 3.0, vendor extensions are denoted by the 'x-' prefix, allowing vendors to add custom properties to OpenAPI objects without conflicting with future specifications. This ensures compatibility and clarity in the use of extensions.