A municipal automation client still holds a Cisco API representation and its ETag. How should the next GET be constructed to optimize bandwidth?
Select an answer to reveal the explanation.
Short Explanation
Show the coat-check stub: if nothing changed, they wave you through without handing the coat back. Pair the stored ETag with If-None-Match so the server can return 304 and skip the body.
Full Explanation
Conditional GET with validators is the standard bandwidth optimization when the client already holds a representation. For the municipal automation client that still holds a Cisco API body and its ETag, the next GET should send If-None-Match with that stored ETag so the server may answer 304 Not Modified without a payload. Unchanged inventory then costs a small validator round-trip instead of a full download—important on constrained civic WAN links.
Omitting validators and always downloading the full body so the client can compare locally fails the optimization: comparison already happened server-side with ETags. Sending If-Match with a random UUID unrelated to the stored ETag fails because If-Match is for conditional writes/concurrency, and a random value will not match the resource’s validator. POSTing the old body back to the same URL to ask whether anything changed fails REST safe-method design and may be interpreted as an unsafe create/update.
Exam caveat: weak vs strong ETags and multipart If-None-Match lists exist; sending the exact stored ETag is the DEVCOR-relevant pattern. Prefer ETag/If-None-Match when both ETag and Last-Modified exist if the API is ETag-centric.
Operational check: capture a second GET with If-None-Match and confirm a 304 with empty/negligible body while the client retains the prior representation, and that bandwidth counters drop versus unconditional GET.