Return to Answer

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.

Another way to consider this; imagine that producing new dynamically generated random data is expensive -- 1000 USD per pop. We certainly wouldn't want to be paying out that fee for spiders that are reviewing the site every day, or when that information is speculatively pre-loaded into the cache.

In such a circumstance, we would not provide access to this resource using safe methods; doing so sends the wrong message to the clients (and intermediate components). Instead, we would insist that access to the resource happen via POST, so that the machines would know not to do the wrong thing.

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.

Another way to consider this; imagine that producing new dynamically generated random data is expensive -- 1000 USD per pop. We certainly wouldn't want to be paying out that fee for spiders that are reviewing the site every day, or when that information is speculatively pre-loaded into the cache.

In such a circumstance, we would not provide access to this resource using safe methods; doing so sends the wrong message to the clients (and intermediate components). Instead, we would insist that access to the resource happen via POST, so that the machines would know not to do the wrong thing.

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.

Another way to consider this; imagine that producing new dynamically generated random data is expensive -- 1000 USD per pop. We certainly wouldn't want to be paying out that fee for spiders that are reviewing the site every day, or when that information is speculatively pre-loaded into the cache.

In such a circumstance, we would not provide access to this resource using safe methods; doing so sends the wrong message to the clients (and intermediate components). Instead, we would insist that access to the resource happen via POST, so that the machines would know not to do the wrong thing.

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.

Another way to consider this; imagine that producing new dynamically generated random data is expensive -- 1000 USD per pop. We certainly wouldn't want to be paying out that fee for spiders that are reviewing the site every day, or when that information is speculatively pre-loaded into the cache.

In such a circumstance, we would not provide access to this resource using safe methods; doing so sends the wrong message to the clients (and intermediate components). Instead, we would insist that access to the resource happen via POST, so that the machines would know not to do the wrong thing.

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.

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.

Another way to consider this; imagine that producing new dynamically generated random data is expensive -- 1000 USD per pop. We certainly wouldn't want to be paying out that fee for spiders that are reviewing the site every day, or when that information is speculatively pre-loaded into the cache.

In such a circumstance, we would not provide access to this resource using safe methods; doing so sends the wrong message to the clients (and intermediate components). Instead, we would insist that access to the resource happen via POST, so that the machines would know not to do the wrong thing.