You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Roy T. Fielding" <fi...@gbiv.com> on 2007/10/15 21:43:52 UTC
Actions (methods) must not appear in URIs
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/%3C20070221162717.942FE1A981A@eris.apache.org%3E>
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
Re: Actions (methods) must not appear in URIs
Posted by David Nuescheler <da...@day.com>.
hi roy,
> 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.
i completely agree with toby.
i see selectors exclusively as a means to display the same
logical content in different ways for example: as html, as pdf, as
a small navigation-images, as an html "teaser" in a list, etc...
generally, i think that selectors are generally only relevant for GETs
anyway.
from what i can see there is absolutely no intention to put http
methods into a selector. i think we never did that, and i am 100%
with you that this would be bad design.
is there anything in particular that makes you think that there is a
danger that this would happen in (micro)sling? maybe we were
not able to articulate the intention of the script mapping when
it comes to methods and selectors properly...
regards,
david
Re: Actions (methods) must not appear in URIs
Posted by Tobias Bocanegra <to...@day.com>.
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 <fi...@gbiv.com> 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/%3C20070221162717.942FE1A981A@eris.apache.org%3E>
>
> 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
>
--
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---
Re: Actions (methods) must not appear in URIs
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Roy,
Thanks for the clarification and links - comments inline.
On 10/15/07, Roy T. Fielding <fi...@gbiv.com> wrote:
> ...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...
If we want to go the extra mile in Sling, we could wrap the JCR
Session to make it read-only when processing GET (or HEAD) requests.
That's not totally trivial as we'd have to wrap the Item, Node and
Property as well, but that might help in avoiding GET abuse.
> ...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"....
Dumb clients (say a mobile phone browser) often make it hard to add
custom HTTP headers to form submissions. What would you recommend in
this case? Using a POST which specifies the actual method as a
parameter, as a second workaround in case the above one is not
possible?
> ...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....
Totally agreed about Sling itself, and your vigilance is appreciated.
About software that people build on top of Sling, I think the best we
can do is to try to educate users in a gentle way, by providing best
practices examples and utilities (like SLING-53).
-Bertrand