A city script caches a rarely changing Cisco catalog GET, then performs a PATCH on one of those resources. What is the correct cache behavior afterward?
Select an answer to reveal the explanation.
Short Explanation
Caching the printed menu helps; caching last week’s order after you already changed it does not. Stable catalog GETs are the win—after a write, do not blindly trust the pre-mutation cache.
Full Explanation
HTTP cache optimization is selective. Rarely changing catalog GETs are ideal reuse candidates. After POST, PUT, or PATCH mutates the same resource, the consumer must not blindly trust the pre-write cache; it should refetch or revalidate. Caching every URL indiscriminately is not correct API usage optimization.