Does WebDav follow the RestArchitecturalStyle? (2PA)
This isn't in any way an authoritative answer, but for the most part it does. The extension methods it defines operate on resources, even existing resources, so that's fine. REST encourages defining new methods in some cases, rather than attempting to overload the meaning of other existing methods. (2PB)
The notion of properties and locks as separate resources accessible via separate methods is a bit different. As is the 207 (Multi-Status) response code. It's difficult to say that these are not REST, but it's probably accurate to say that they stretch REST is some interesting ways. Hrmm... (2PC)
While I agree that WebDAV? is RESTful, I disagree with the second statement above. WebDAV? does not maintain the notion that properties and locks are seperate resources. Properties and locks do not exist separately from the resources they belong to, and hence are not subject to having any methods applied to them at all in the sense implied above. (2PD)
Right, I think that's part of the problem. Properties and locks should exist separately from their resources, and be resources themselves. They sort of are, in that they get URIs, but then GET isn't used on them. See Dan Connolly's message on the problems with PROPFIND, for example. -Author unknown (2PE)
Elias' reply: Let's consider what you are saying a bit further... If properties and locks were modeled as being distinct resources, how should they respond to other HTTP / WebDAV? methods? For example, what does it mean to GET a lock? How about MOVE or COPY? I think you can see what I'm getting at. As I said above, the WebDAV? methods operate on RESOURCES, not locks or properties, and this agrees wholey with the basic RESTful style of resource interaction. (2PF)
Regarding Dan Connelys' email to the www-tag list, do note that the message was written in early 2002... Anyway, his statement is presently incorrect. The issue he brings up about how a server responds to GET on a collection by listing it's members was with respect to a particular (possibly non-compliant) python WebDAV? sever. With a current build of Apache2 (which employs mod_dav, the standard reference implementation of RFC2518) the contents of a collection ARE returned in response to a GET request. (2PG)
The PROPPATCH, PROPFIND, LOCK and UNLOCK methods operate upon resources themselves, just as the other methods do. They do, however, have the side-effects of manipulating metadata associated with a resource. (Even a lock on a resource can be thought of in this way.) (2PH)
207 responses seem very similar to multi-part MIME encodings... I agree that this is not very RESTful, but it certainly doesn't stretch the principles of REST beyond what has already been done by HTTP/1.1. What we are seeing here is a tension between the ideals of an architectural style and the concessions made in the implementation of that style for the sake of performance. (2PI)
WebDAV? is not RESTful. It treats URLs as hierarchical rather than opaque. (2PK)
To be RESTful a resource collection would simply be a file enumerating a set of URLs. (2PL)
WebDAV? collections rely on '/' to delimit collection hierarchy. From RFC2518 (2PM)
"For all WebDAV? compliant resources A and B, identified by URIs U and (2PN)
V, for which U is immediately relative to V, B MUST be a collection that has U as an internal member URI. So, if the resource with URL http://foo.com/bar/blah is WebDAV? compliant and if the resource with URL http://foo.com/bar/ is WebDAV? compliant then the resource with URL http://foo.com/bar/ must be a collection and must contain URL http://foo.com/bar/blah as an internal member." (2PO)
I would be very interested in seeing some more development of these themes. I have been scouring the web, and this wiki, for detailed exploration of the boundaries of container and resource semantics and the role of hyperlinking. For example, PaulPrescod expanded quite a bit on the role of hyperlinking in REST, parallel to the role of hyperlinking on the web in general, in his "REST and the Real World" article, http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html. However, I have seen very little discussion, and examples, that dive into the use of XML linking technology to hyperlink the resources in containers as populated by POSTs. WebDAV? has the notion of a recursive GET verb, so that the decomposition of the contained resources may be delivered as an inline XML document. Does this concept co-exist with REST? I suspect that there is a way to permit REST operations over both the decomposed and non-decomposed representation of a REST-ful container. (2PQ)
Just to be explicit, a decomposed version of a container would inline the XML of its container resources, e.g., until the logical tree bottoms out. For a graph, and not just a tree, this notion of decomposition would have to be defined in terms of some traversal algorithm that broke cycles in the graph. However, I am happy to limit this discussion to simple container systems. (2PR)
207 responses seem very similar to multi-part MIME encodings... I agree that this is not very RESTful, but it certainly doesn't stretch the principles of REST beyond what has already been done by HTTP/1.1. What we are seeing here is a tension between the ideals of an architectural style and the concessions made in the implementation of that style for the sake of performance. (2PT)
207 response is RESTful as long as it is a result of "single-purpose" operation. PROPFIND satisfies this. It goes unRESTful when you use 207 to return result of "bundled" independent operation. That will violate transparency of the protocol just like XML-RPC and "RPC-ish" SOAP does. (2PU)
WebDAV? is not RESTful. It treats URLs as hierarchical rather than opaque. (2PV)
I guess semantic of "recursive" DELETE/COPY/etc. required hierarchical model. But this also introduced a tight binding between resources and so is in conflict with loose structure of the Web. It is practically avoided by handling local-part (pathname) of URI special, but it's going to be a headache once you try to extend this model beyond single host namespace. How do you tightly couple resources under decentralized environment? Resulting system would be both fragile and unRESTful. (2PW)
BryanThompson asked about bundling. A more natural bundling format would be multipart/digest or multipart/mixed. That way each part can carry content-type and other header information that would be associated with a GET to the resource. What might be missing is the URL associated with each part. But there is no reason that each part, could not include a Location: header to provide that. (2PY)
Then again, I think hierarchy in URL space is bad design so take all of this with a grain of salt. (2PZ)