RE: draft findings on Unsafe Methods (whenToUseGet-7)

Folks,

So first off, I am mostly ok with what Dan has written. In particular I am
ok with the SHOULD in :

>      * safe methods (GET/HEAD) should be used for safe operations: read,
query, view, ask, lookup

and mostly with the MUST NOT (might want to think about SHOULD NOT or MUST
NOT, the latter is probably right) in:

>      * safe methods must not be used for unsafe operations: write, update,
modify, tell, buy, agree

Largely for the reasons expressed by Tim Bray [1], the first SHOULD is not
an absolute prohibition, but there is recognition that the Web may loose
something when you make a different choice.

It is interesting that Dan annotates the methods with a list of
operations... which heads of in a direction of adding verbs... (just an
observation).

Wrt to safety and RFC 2616. I don't think that the concept of safe methods
is well articulated. Section 9.1.1 seems somewhat tentative, speaking in
terms of a "convention" that GET and HEAD *should be* safe and *should be*
without side-effects that the user is unaware of or will be held accountable
for.

RFC 2616 does not rule out the use of POST for safe operations (at least
section 9.1.1 doesn't rule it out)... not a complaint.

The other argument against the use of POST, particularly as exemplified in
SOAP is the hiding of information or the creation of 'private address
spaces' behind Web Service interfaces. Essentially the creation of resources
that are hidden by virtue of the fact that they are not directly addressable
by URI. This has been picked up by several folks [2].

For my sins I have been an (active) member of the XML Protocol WG and have
been wrestling for some time with the two views of SOAP often referred to as
the Chameleon view (SOAP takes on the character/nature of the infratructure
to which it is bound) and the Tunneling view (that SOAP provides a
communication abstraction of its own that is independent of the
infrastructure that it is bound to). For the most part I have come at XMLP
from a tunneling point-of-view. If SOAP is a protocol I ought to be able to
articulate what (communication) services it provides to the things that use
it and that by and large the things application entities use SOAP should not
have to have detailed knowledge of the infrastructure to which SOAP is
bound, only of the abstraction that SOAP presents them to use. This is
pretty much the principle of generic interface applied to SOAP - it's just
that the interface is *not* characterised by the operations
GET/PUT/POST/DELETE... is an interface centred on primitives for the
exchange of messages between peer application entities (clients of the SOAP
layer - and this is admittedly a very layerist pov).

Of late I have been trying to make some good-faith effort reconcile these
two views in REST terms, and the closest I have come is to thinking of the
SOAP entities identified by URIs that are the senders and recipients of SOAP
messages as messaging endpoints. The use of POST to transfer a message is
asking that end-point to accept the body of the HTTP request as a
subordinate entity of the target resource - an entry in the message queue.
At present SOAP does not make use of the location header to provide a URI to
make future reference to that entry (for query and status purposes), but it
could (would take some futher definition etc.). One could the look to find
out the disposition and processing results from that message by some futuer
GET on a simple URI, which of course might clone the result that may have
been returned (or not) in-line with the original POST response. Some will
continue to 'complain' that the resources identified by the contents of the
message body still remain hidden behind a service interface and are still
not directly accessible by URI and true... this has done nothing to  expose
those resources. But... in the REST sense, it has exposed the  messaging
endpoint as a resource and there is the potential to expose the queued
messages that endpoint as resources and take the view that the HTTP message
bodies are representations of the state of queue entries.

There may be other ways the cast SOAP in REST terms.

On the matter of hidden resources I have some sympathies (but not
solutions). It seems that caching and bookmarking are the things that
suffer, as noted by others [1]. But... on one level it seems to me that all
the various syntactic elements are there, just not in the right places for
some. Nouning verbs moves verbs into the URI and makes them visible to web
infrastructure, it doesn't remove the 'verb' from the picture. Likewise,
shifting parameters to query strings... so at some high-level there really
is no difference in the achieveable functionality (except bookmarking).
Hiding resources from Web infrastructure may make things less
optimal/scalable by defeating caching strategies, but some also also suggest
that this is not the huge problem that it's sometimes presented as [3].

I am very supportive of David Orchards suggestion of liason between the TAG
and the WSAWG [4] and would be happy to participate in such an activity.

Regards

Stuart Williams
(Speaking soley for himself).

[1] http://lists.w3.org/Archives/Public/www-tag/2002Apr/0160.html 
[2] http://lists.w3.org/Archives/Public/www-tag/2002Apr/0167.html
[3] http://lists.w3.org/Archives/Public/www-tag/2002Apr/0164.html
[4] http://lists.w3.org/Archives/Public/www-tag/2002Apr/0154.html

> -----Original Message-----
> From: Dan Connolly [mailto:connolly@w3.org]
> Sent: 15 April 2002 16:51
> To: www-tag@w3.org
> Subject: draft findings on Unsafe Methods (whenToUseGet-7)
> 
> 
> This got some discussion in today's telcon,
> but folks haven't really had a chance to read it;
> I'm trying to figure out whether I'm mostly
> done and should just polish off the few remaining
> @@TODOs, or whether the essential guts need work.
> 
> 
>   DRAFT Findings on Safe Methods
>   on issue whenToUseGet-7
> 
>   DRAFT by Dan Connolly, for the TAG
>   $Revision: 1.5 $ of $Date: 2002/04/15 14:26:17 $ by 
> $Author: connolly
> $
> 
>   http://www.w3.org/2001/tag/doc/get7
> 
> 
> text copy:
> 
> --8<--
>  A great deal of the utility of the Web depends on the 
> ability of users
>    (and agents) to explore the shared information space safely; to
>    explore a page and come back, without channging anything. A very
>    important principle when designing Web applications is:
>      * safe methods (GET/HEAD) should be used for safe 
> operations: read,
>        query, view, ask, lookup
>      * safe methods must not be used for unsafe operations: write,
>        update, modify, tell, buy, agree
> 
>    Though the principle applies to ftp (CHDIR and RETR are 
> safe; PUT is
>    not) and other protocols, most Web applications are built 
> using HTTP;
>    it is critical to build these applications with an awareness of the
>    following section of the HTTP specification:
> 
>      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.
> 
> 
>     [4]9.1.1 Safe Methods, HTTP 1.1
> 
>       [4] 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1

   It is also very important to keep this principle in mind when using
   HTML forms:

     The "get" method should be used when the form is idempotent (i.e.,
     causes no side-effects). Many database searches have no visible
     side-effects and make ideal applications for the "get" method.

     [5]17.13.1 Form submission method of HTML 4.01 (text has been in
     HTML spec back to [6]HTML 2.0)

      [5]
http://www.w3.org/TR/1999/REC-html401-19991224/interact/forms.html#h-17.13.1
      [6] http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.2

Applications that depend on safe methods

   A wide variety of applications depend on the safety property of HTTP
   GET:
     * search service crawlers
     * caching proxies

   not to mention the importance of the ability of users to explore
   safely. (@@cite stats about the popularity of the back button)

Example: mailing list subscription

   Consider the following two designs for mailing list subscription
   confirmation; in the first case:
    1. The user sends a subscribe message to an administrative mailbox
       (mylist-request@example.org).
    2. The list processing software requests confirmation by email,
       including a link to a confirmation page
    3. The user visits the confirmation page, and finds a "[Confirm]
your
       subscription" form, with method="POST".
    4. The user activates the [Confirm] form control.
    5. The list processing software confirms the subscription.

   In the second case:
    1. as above
    2. as above
    3. The user visits the confirmation page and sees "your subscription
       is confirmed". The list processing software confirms the
       subscription.

   The latter design performed an unsafe operation (list subscription)
in
   response to a request with a safe method (following the link from the
   mail message with GET).

--8<--

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 16 April 2002 11:22:54 UTC