Operations whose content changes rarely emit an ETag header carrying the signature of the response:
ETag: "a1b2c3d4e5f6..."
Cache-Control: private, max-age=3600Returning that signature on the next request lets the server answer 304 when nothing has changed:
GET /v1/public/banks
If-None-Match: "a1b2c3d4e5f6..."A 304 carries no body. It confirms that the client's copy is still current, without transporting the resource again.
Where it applies
22 operations emit an ETag, in three classes:
| class | example | why |
|---|---|---|
| Catalogues | GET /v1/public/banks | Change weekly and are read on every session |
| State polling | GET /v1/validations/{id} | Queried repeatedly while the state does not change |
| Operations dashboards | Queues and their streams | Continuous refresh over data that often does not vary |
Each one declares it on its reference page. The remaining operations emit no ETag, and sending If-None-Match to them produces no error: it is simply ignored.
Shape of the signature
Catalogues use a strong quoted signature. Validations use a weak signature encoding version and state — W/"3-processing" — so any transition changes the value. In both cases client handling is the same: keep the value received and send it back without interpreting it.
Client handling
- Store the
ETagalongside the response. - Send it as
If-None-Matchon the next request for the same resource. - On a
304, reuse the stored copy; on a200, replace it along with its newETag.
In polling an asynchronous validation, this mechanism is what avoids downloading the same resource on every attempt while the state has not advanced.