Graham Klyne wrote:

It isn't about visibility. We're not talking about programming languages. I think that the HTTP specification is clear that it is about *responsibility*.

"Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them."

A safe operation is one that a service provider commits to executing over and over, anytime, or more than once, or never. It's a contract that says that the user will never be penalized in any way for executing the method.

Safety is important because when a program processes hypertext (in the general sense of nodes with arcs), it may follow arcs over and over again, whenever it feels like, and may pass node references to other processes which will also follow arcs over and over again, whenever THEY feel like it. You cannot do that if the act of following an arc may have an implicit constraint like: "you should only follow it once, or only after following that other arc in the last five minutes."

That's why Roy is right that labeling the operation *after the fact* is almost always a waste of time.

The HTTP specification uses the term idempotent to mean idempotent.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2

PUT is safe but not idempotent.

Agreed.