Graham Klyne wrote:
>
>...
>
> This suggests two possible ideas of "safe":
>
> - an operation that has no (externally visible) side effects
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.
> - an operation that is idempotent: has no further side effects if repeated
> after it has been performed once
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.
> In the context of GET, I think the first is desired/needed.
Agreed.
Paul Prescod