I seem to have failed to get my point across when I last visited
Basel and we talked about what can and cannot be done in a selector.

The original Web design notes forbid the use of GET for any action
that is considered to have "side-effects", because such an
implementation allows users to be tricked into performing
actions that they cannot anticipate.

    http://www.w3.org/DesignIssues/Axioms.html#state

REST requires that identification (via URI) be independent within the
generic interface of Methods applied via messages, since failure
to maintain that separation means that intermediaries will cause
unanticipated actions to be applied that are unsafe.

HTTP/1.1 (RFC 2616) states:

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in
   their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an
   unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods SHOULD NOT have the significance of taking an action
   other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
   and DELETE, in a special way, so that the user is made aware of the
   fact that a possibly unsafe action is being requested.

   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.

9.1.2 Idempotent Methods

   Methods can also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of N > 0 identical
   requests is the same as for a single request. ...

And the URI spec (RFC 3986) says:

1.2.2.  Separating Identification from Interaction

A common misunderstanding of URIs is that they are only used to refer
   to accessible resources.  The URI itself only provides
   identification; access to the resource is neither guaranteed nor
   implied by the presence of a URI.  Instead, any operation associated
   with a URI reference is defined by the protocol element, data format
   attribute, or natural language text in which it appears.

Even the HTML 2.0 spec (RFC 1866) said:

   If the processing of a form is idempotent (i.e. it has no lasting
   observable effect on the state of the world), then the form method
   should be `GET'. Many database searches have no visible side-effects
   and make ideal applications of query forms. ...

   If the service associated with the processing of a form has side
effects (for example, modification of a database or subscription to a
   service), the method should be `POST'.

In other words, if a selector is used to indicate a desired action
(or, in general, if any part of a URI is allowed to contain an
action that would override the role of METHOD in HTTP), then the
software violates three Internet standards, TimBL's original design,
and my formalization of the REST architectural style.

The reason for such repeated mentions of this same requirement,
over and over, is because every time such a wrong-headed application
of the Web has been exposed on the Internet it has resulted in
mass customer data loss and ensuing lawsuits.  EVERY TIME.
The Web was intentionally designed to allow robots and anticipatory
browsing techniques (link prefetching, caching, etc.) to proceed
based on the presence of a URI within a GET context.  That's the
way it is supposed to work.

Obviously, we did not anticipate that browser authors would make
it difficult to use the other HTTP methods when appropriate.  The
most common workaround for broken browsers (used only after an
initial request using the real method fails) is to use a POST
request (known unsafe) and include the real method in a header
field called "X-HTTP-Method-Override" or "X-Method-Override", e.g.

<http://code.google.com/apis/gdata/basics.html#Updating-an-entry>
<http://mail-archives.apache.org/mod_mbox/incubator-abdera-commits/ 200702.mbox/[EMAIL PROTECTED]>

I don't *like* this solution, since it still provides a route
around what should be legitimate firewall intermediaries that
block specific methods, but I understand the need for it.
Moreover, it is far less dangerous than placing actions
within any part of the URI (where they are invoked by GET).

In any case, actions within URIs is the most anti-REST thing
possible.  In addition to causing the unanticipated action-effects
described above, they force the hypertext to be tightly-coupled
to the server framework, which loses much of the coupling-free
effects of the architectural style.

I would be compelled to piss on any software that did such a
horrible thing (and have done so many times in the past).
If Sling is going to claim to be a RESTful framework, it must
protect the original design goals and obey the separation of
concerns within the generic interface of HTTP.  And that
applies equally to any software we build on top of Sling.

....Roy

Reply via email to