A Cisco API provides Last-Modified on a GET response but no ETag. How should the consumer optimize the next GET?
Select an answer to reveal the explanation.
Short Explanation
No ticket stub? Use the date stamp on the package instead. Last-Modified plus If-Modified-Since is the date-based twin of ETag validation—same family of savings, no vendor extension required.
Full Explanation
When a Cisco API provides Last-Modified on a GET but no ETag, conditional requests can still use time-based validators. The municipal consumer should send If-Modified-Since using that Last-Modified value so an unchanged body can be skipped with 304 Not Modified. That keeps civic clients efficient even on older or simpler endpoints that never emit ETags, while still asking the origin whether the representation changed.
Inventing a synthetic ETag by hashing the body client-side and sending If-None-Match only fails because the server did not issue that validator and will not recognize the client hash as its ETag. Disabling caching entirely whenever ETag is absent fails by abandoning a perfectly usable Last-Modified path the platform already offered. Requiring a proprietary Cisco cache product before any conditional request is allowed fails the standards-based HTTP caching model DEVCOR expects of application clients.
Exam caveat: clock skew and sub-second updates can make Last-Modified coarser than ETags—still correct when it is what the API offers. Do not send If-None-Match with a homemade value “just in case,” and prefer the server-provided validator family actually present on the response.
Operational check: store Last-Modified from the first GET, send If-Modified-Since on the next poll, and confirm 304 reuse when content is unchanged, with a full 200 body when the resource’s modification time advances on the Cisco side.