After a conditional GET, a Cisco API returns HTTP 304 Not Modified with an empty body. What should the consumer do?
Select an answer to reveal the explanation.
Short Explanation
The clerk saying “your copy is still good” is not the same as handing you a blank clipboard. On 304, keep the stored body—do not interpret the empty payload as “the list is now empty.”
Full Explanation
HTTP 304 Not Modified means the client’s cached representation is still current; the empty body is intentional. After a conditional GET to a Cisco API returns 304, the consumer must reuse the previously stored representation and treat 304 as cache success—not as an empty list, deleted resource, or error. Parks or facilities dashboards that wipe local state on empty bodies will falsely show zero sites after a perfectly healthy validation.
Replacing the local list with an empty array because the payload contained no items fails by misreading 304 semantics. Deleting the resource locally and issuing DELETE to match the empty response fails catastrophically: you mutate production based on a cache validation success. Treating 304 as equivalent to 404 and removing the identifier from inventory fails for the same reason—304 affirms the resource still exists with the same validator.
Exam caveat: a 200 with an empty JSON array is a different outcome from 304; only 304 licenses reuse of the prior body. Update Age/freshness metadata on 304 as your cache implementation requires.
Operational check: after forcing If-None-Match and receiving 304, assert the UI still shows the prior site count and that no DELETE or inventory-removal side effects run.