- From: Paul Prescod <paul@prescod.net>
- Date: Thu, 18 Apr 2002 00:34:04 -0700
- To: Graham Klyne <GK@ninebynine.org>, www-tag@w3.org
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
Received on Thursday, 18 April 2002 03:33:14 UTC