RE: POST vs. separate methods

Actually the server people and the client people love the POST idea
because it is fully backwards compatible with everything out there. By
implementing the new functions through POST we can take any currently
existing server and client and have it work with the system. 
				Yaron

>-----Original Message-----
>From:	Roy T. Fielding [SMTP:fielding@liege.ics.uci.edu]
>Sent:	Tuesday, November 05, 1996 8:30 PM
>To:	w3c-dist-auth@w3.org
>Subject:	Re: POST vs. separate methods 
>
>Jim summarized ...
>> In a nutshell, Roy and Yaron differ in their model of a web server.  Roy
>> sees a web server as a collection of objects, with methods defined on them,
>> a la object-oriented programming.  Yaron sees a web server as a collection
>> of agents (computational entities), of which some serve documents, while
>> others perform activities like "copy" or "server diff."  In fact, there may
>> be many agents capable of performing an activity, and a single agent may be
>> capable of handling more than one type of activity.
>
>Ummmm, not quite.  My view (and my experience) is that HTTP is an interface
>mechanism between clients and servers. Any reduction of that interface based
>on the assumed needs of one particular implementation of an HTTP server
>is just plain wrong -- wrong because it limits the possible implementations
>of whatever it is you want to accomplish.  JigSaw and Apache are two very
>different ways of implementing a server, but both ways have their advantages.
>(JigSaw is OO-based and Apache is handler-based).  Likewise, a Hyper-G
>server's view of what a "directory" may be is substantially different from
>that of the NCSA or CERN servers.  Nevertheless, everything that you might
>want to do in the way of distributed authoring can be done in such a way
>that the implementation is independent of the interface, unless you make
>the mistake of assuming things about the implementation when you design
>the interface.
>
>HTTP includes methods (that define actions) and resources (that define the
>point of the server's namespace) and parameters (request headers) and
>data (entity headers and body). What the server does with those things
>is defined by the semantics of the method and acknowledged by the server's
>response (including Vary, if necessary).  How the server does it is none
>of HTTP's business.
>
>> The advantages of the Object Oriented view stem from the fixed set of
>> methods: this fixed set is understood better by existing Web technology
>> (e.g., caches), and can be used to implement a simple access control scheme
>> (method x user --> ACL).
>
>Gack! Bzzzzt.  There is no such thing as a fixed set of methods, and the
>fact that all (not just simple) access control schemes are based on the
>method is because the method defines the semantics for the request or,
>in the singular case of the POST method, the resource is given complete
>control over the semantics.  The notion that the media type defines those
>semantics is totally unchartered territory.
>
>I understand that it is possible to ignore that and to do everything under
>a single method and to encapsulate the semantics of the request within
>the message body.  The reason we don't do that is because it is simpler
>for a client (which must consider the presentation of the semantics)
>and a server (which may have multiple layers of access control) to embody
>the semantics of a request within the method.  Aside from access control,
>it also frees the media type from having any semantics other than
>"this is the format of what is contained within the body." 
>
>All of the above are (at least some of) the technical arguments regarding
>why actions should be defined as methods and not as media types.  If you
>would like a religious argument as well, then: That's the way we've always
>done it, and that's the way we've implemented the existing Web, so that's
>the way I would expect any standard to develop unless there is a good reason
>against it.  If we are talking about extensions to HTTP/1.x, then I expect
>those extensions to follow the framework of HTTP.  If you don't like that
>framework, then there is nothing stopping you from defining a protocol
>which is not HTTP/1.x, or extend some other protocol, like z39.50 or FTP,
>which have different frameworks.  What you lose is the existing
>implementation base and the advantages provided by HTTP's generic
>interface, but you will lose that anyway if you require things that do not
>correspond to the existing framework.
>
>.....Roy
>

Received on Wednesday, 6 November 1996 19:03:00 UTC