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 Tuesday, 5 November 1996 23:31:40 UTC