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

> In particular, there are other reasons for using POST,
> namely that GET does not take a body, and trying to add
> a body to GET requests would introduce significant
> incompatibility. A "safe" operation which also involves
> file upload, for example, should not encode the file
> data in the URL.

File upload is not a safe operation. In general, most applications
that involve user-supplied data being supplied to the server are not
safe.  The only exception is when the information is in the form of
generalized query parameters, for which there is a trade-off between
GET and POST that usually involves the size of the parameter content.
GET is only desirable for those cases where the parameters can be
expressed as a meaningful URI.

As I mentioned on the conference call, it would be far more effective
to tease out the principles of the Web and define those, rather than
express edicts about the use of HTTP.  The fact of the matter is that
most CGI scripts are not HTTP compliant.  Most CGI scripts, in fact,
provide interfaces to applications that suck. The "G" stands for Gateway.
What people should realize is not that "CGI scripts should be banned",
but rather that if the CGI script is written such that it behaves
like a proper Web interface, then it won't suck.  The point is to
describe to developers the ways in which an interface can be better
implemented on the Web.  REST is not the easiest way to provide an
interface on the Web.  In fact, doing it right requires fairly
sophisticated software.  CGI makes life easy for programmers.
REST-like operation makes life easy for users and content maintainers.

The problem with SOAP is that it tries to escape from the Web
interface.  It deliberately attempts to suck, mostly because it
is deliberately trying to supplant CGI-like applications rather
than Web-like applications.  It is simply a waste of time for folks
to say that "HTTP allows this because I've seen it used by this
common CGI script."  If we thought that sucky CGI scripts were the
basis for good Web architectures, then we wouldn't have needed a
Gateway Interface to implement them.

In order for SOAP-ng to succeed as a Web protocol, it needs to start
behaving like it is part of the Web.  That means, among other things,
that it should stop trying to encapsulate all sorts of actions under
an object-specific interface.  It needs to limit its object-specific
behavior to those situations in which object-specific behavior is
actually desirable.  If it does not do so, then it is not using URI
as the basis for resource identification, and therefore it is
no more part of the Web than SMTP.

> The HTTP working group's conclusion on this topic over
> a significant amount of discussion was that, if we
> wanted to do anything about this, we should add the
> "Safe:" result header. However, there was no consensus
> that there was any desire to know whether POST methods
> were Safe or not, so RFC 2310 remains as "Experimental".

I think that is stretching it.  The HTTP-WG never reached
any conclusion on the topic.  The Safe header field was not
implemented because it is utterly pointless to know whether or
not a message is safe *after* it has been invoked.  We already
have other means to mark whether or not content can be cached,
and caches won't use anything other than a URI and simple
header field content as a cache key.


Cheers,

Roy T. Fielding, Chairman, The Apache Software Foundation
                  (fielding@apache.org)  <http://www.apache.org/>

                  Chief Scientist, Day Software
                  2 Corporate Plaza, Suite 150
                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
                  (roy.fielding@day.com) <http://www.day.com/>

Received on Tuesday, 16 April 2002 22:57:35 UTC