- From: Roy T. Fielding <fielding@liege.ics.uci.edu>
- Date: Tue, 05 Nov 1996 20:30:23 -0800
- To: w3c-dist-auth@w3.org
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