[rileymat2]

> This allows us to invoke GETs safely any number of times in any order and get the same results each time. An important consequence of this is that it allows any participant in the routing of requests to use caching, which is a key element in making the web perform as well as it does.

What conditions for a restful api does this come in handy?

In most implementations I have had the requests are as quick to figure out if anything has changed as it is to return the result.

The problem is not that a get changes the result, it is a post from some other client has changed it in the interim and you want the freshest data.

Id imagine it is most useful in serving static content that has large payloads, which most of my apis don’t serve.

[schnable]

Static content by definition doesn't change so this rule isn't for that case. Caching benefits even dynamic content, and dealing with cache invalidation is a separate problem than what is being discussed here. Your clients may always want the freshest content, but that often isn't scalable. If it is, you can put no expiration in your cache headers and let 'er rip. But you should still respect the idempotency of GET requests.