According to RFC 2616 (emphasis mine)
Note that RFC 2616 is obsolete; it has been replaced by RFC 7230->RFC 7235. "Safe" is now defined in RFC 7231
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
...The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
I regularly use https://www.uuidgenerator.net/ when I need an identifier to use in a answer, and the API they provide is safe, even though the representation of that page changes every time I hit it (the Cache-Control header provided by the server specifies that the page should be re-fetched each time we need a representation of the resource).
I'm not sure if this is the case though as there is no true resource being accessed since the data is generated dynamically.
REST has a very flexible definition of resource
Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a resource.