> 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][1]

> 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][2] has a very flexible definition of [resource][3]

> 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.


  [1]: https://tools.ietf.org/html/rfc7231#section-4.2.1
  [2]: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
  [3]: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1