Conditional requests in REST are HTTP requests executed differently based on the value of specific headers. They allow a client to ask a server to send or modify a resource only if a specific condition is met.
Conditional requests solve two main problems in RESTful architectures
- Caching/bandwidth optimization (for Safe methods like
Get)- Optimistic Concurrency control (for Unsafe methods like ,
Put,PatchorDelete)
This mechanism is primarily powered by two concepts:
- Validators (metadata tracking resource state)
- Precondition Headers (the actual conditions sent by the client).
The Core Validators
Before a client can make a conditional request, the server must provide a validator in the response headers of an earlier request. There are two main types:
ETag (Entity Tag):
- A unique, opaque string identifier (like a hash or fingerprint) representing a specific version of a resource.
- If the resource data changes, the ETag changes.
Last-Modified:
- A timestamp indicating exactly when the resource was last updated on the server.
- Primary Use Cases & Headers
Primary Use Cases & Headers
Caching and Resource Validation - (Safe Methods : GET )
Abstract
Instead of downloading a large resource repeatedly, a client can check if its cached version is still fresh.
If-None-Match
The client sends the cached ETag. The server checks if the current resource ETag matches.
- If it matches
- The server responds with and an empty body, saving significant bandwidth.
- If it doesn’t match
If-Modified-Since
The client sends a timestamp. If the resource hasn’t changed since that time, the server returns a 304 Not Modified
Optimistic Concurrency Control - (Unsafe Methods: PUT, PATCH, DELETE) )
Lost update
- When multiple clients attempt to update the same resource simultaneously, a lost update problem can occur where one user silently overwrites another’s changes.
- Conditional headers act as a check to ensure updates happen sequentially.
If-Match
The client sends the ETag of the resource version they originally fetched and edited.
- Success:
- If the server’s current ETag matches the header, no one else has modified it. The update succeeds (
200 OK** or **204 No Content).
- If the server’s current ETag matches the header, no one else has modified it. The update succeeds (
- Failure:
If-Unmodified-Since
The client requests that the update proceed only if the resource has not been altered since a specific timestamp. If it has changed, it fails with a 412 Precondition Failed
Quick Comparison Table
| Scenario | HTTP Header | Target Verb | Expected Success | Expected Failure |
|---|---|---|---|---|
| Check if cache is fresh | If-None-Match / If-Modified-Since | GET | 304 Not Modified (Use Cache) | 200 OK (New Data Sent) |
| Prevent lost updates | If-Match / If-Unmodified-Since | PUT / PATCH / DELETE | 200 OK / 204 No Content | 412 Precondition Failed |
AI responses may include mistakes.
[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Conditional_requests
[2] https://www.w3schools.in/restful-web-services/conditional-requests
[3] https://developer.salesforce.com/docs/platform/api-rest/guide/intro-rest-conditional-requests.html
[4] https://zuplo.com/learning-center/optimizing-rest-apis-with-conditional-requests-and-etags
[5] https://firebase.blog/posts/2017/07/introducing-conditional-rest-requests/
[6] https://www.oreilly.com/library/view/restful-web-services/9780596809140/ch10.html
[7] https://www.azion.com/en/learning/performance/what-are-conditional-requests/
[8] https://stackoverflow.com/questions/64681296/http-conditional-requests
[9] https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api
[10] https://docs.spring.io/spring-data/rest/reference/etags-and-other-conditionals.html
[11] https://asoasis.tech/articles/2026-05-15-0253-rest-api-conditional-requests-if-modified-since/