Test your knowledge of HTTP and REST essentials as they relate to database APIs. This quiz covers status codes, pagination practices, idempotency, and the use of ETags and If-Match headers to manage RESTful data operations effectively.
Which HTTP status code indicates a successful resource creation when using a POST request to a database API?
Explanation: The correct status code for a successful resource creation via POST is 201 Created, signifying that a new resource has been made. 200 OK is more general and usually signals a generic successful request, not specifically the creation of something new. 404 Not Found suggests the endpoint is missing, and 301 Moved Permanently refers to resource relocation, unrelated to successful creation.
Which approach is most commonly used to paginate results in a RESTful database API when querying a large collection?
Explanation: Limit and offset query parameters allow clients to request only a subset of data, helping manage large result sets efficiently. Sending all results at once is not scalable for large datasets. Results are rarely included in HTTP headers due to size limits and practicality. Assigning page numbers to resources is non-standard and less flexible than using limit and offset.
Which HTTP method is considered idempotent and safe for deleting a database record?
Explanation: DELETE is an idempotent method in REST: repeating the same DELETE request produces the same result after the initial deletion. POST is generally not idempotent since it often creates resources. CONNECT is used for establishing tunnels, not typical database interactions. PATCH is for partial updates and is not guaranteed to be idempotent.
What is the main purpose of using ETags in HTTP headers when interacting with database APIs?
Explanation: ETags help manage version control of resources by providing a fingerprint representing the content version, ensuring safe updates and concurrent modification handling. They are not used for authentication, which secures user access. Data encryption and rate limiting have different purposes—protecting data privacy and controlling request frequency, respectively.
When updating a database record using a RESTful PUT request, what does the If-Match HTTP header help prevent?
Explanation: If-Match ensures that updates occur only if the resource matches a specific ETag, protecting against lost updates from simultaneous users. It does not address slow internet speeds, which are unrelated to concurrency. Resource duplication is handled by other means, and automatic login is part of authentication, not HTTP conditional requests.
If a client tries to retrieve a database resource that does not exist, which HTTP status code should the API return?
Explanation: 404 Not Found properly indicates that the requested resource does not exist on the server. 401 Unauthorized signals authentication failure, not absence of a resource. 409 Conflict refers to data conflicts, while 202 Accepted means the request is received but not processed yet, which is unrelated to missing resources.
Which HTTP method is typically classified as both safe and idempotent when used with database APIs for fetching data?
Explanation: GET is used to retrieve data without causing side effects, making it both safe (no resource modification) and idempotent (repeated requests yield the same result). PUT can modify or create resources, DELETE removes resources, and POST is not idempotent nor safe, as it often changes server state.
When a PATCH request successfully updates part of a database resource, which HTTP status code is most appropriate for the API to return?
Explanation: A successful PATCH request typically returns 204 No Content to indicate success without content in the response body. 403 Forbidden indicates lack of permissions, not success. 502 Bad Gateway reflects upstream server errors, and 305 Use Proxy is rarely used and unrelated to successful updates.
What should a RESTful database API include to let clients efficiently navigate large paginated result sets?
Explanation: Providing links or metadata about next and previous pages (in response headers or body) helps clients traverse paginated results easily. Including tables in the request body is not a standard navigation method. Random selection defeats pagination's purpose, and hard-coded sorting lacks the flexibility required for diverse client needs.
To ensure idempotency when creating a resource via POST, what should an API require from the client?
Explanation: A unique request identifier (like an Idempotency-Key header) allows the API to recognize repeated requests and avoid duplicate resource creation. Listing all previous requests is impractical and not standard. The database schema is unnecessary for individual requests, and a password reset token relates only to authentication, not idempotency.