thanks for this clarification. but how i see the current design of (micro)sling - there is not any intention of 'storing' actions in the uri. of course a user can still code some 'actions' in his script - but this would not be the fault of sling. the 'selectors' are primarily used to resolve to a different 'view' of the content, or to pass additional render information, e.g. the dimensions of a resized image.
regards, toby On 10/15/07, Roy T. Fielding <[EMAIL PROTECTED]> wrote: > 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 > -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
