-
"WebDAV stands for "Web-based Distributed Authoring and Versioning". It is a set of extensions to the HTTP protocol which allows users to collaboratively edit and manage files on remote web servers."
WebDAV also follows the REST Architectural Style.
See also:
-
WebDavVsAtom, the similarities and differences between Atom and WebDAV
Relationship between Atom and WebDAV
Given that both Atom and WebDAV support remote management of web sites, what is the relationship between them? Are they competing for the same space, or do they have different goals? If the latter, will Atom be interoperable with WebDAV? What are the similarities and differences? In what scenarios should Atom be used, and in what scenarios should WebDAV be used?
I can't answer this question, but I'm hoping that others can. In the meantime, I have compiled what relevant links I can find, though:
* From the atom-syntax mailing list, JoeGregorio responds to pillbug, who asked why not just use WebDAV:
> Let me close with a modest proposal: it seems like the existing RESTful > approach to browsing available resources and selectively retrieving > metadata is to use WebDAV. Why define a whole new schema for retrieving > XML describing the metadata of collections of resources when WebDAV > already has one? If you can handle WebDAV why bother working with the AtomAPI at all? No really, I'm serious, if you can handle the complexity and server requirements of WebDAV, then why do you need that AtomAPI? Use Blosxom to run your weblog and then under Windows you can map a WebDAV directory to a drive letter. That way you can use your favorite text editor on your local machine to edit your entries on your site. -joe
* KenMacLeod responds:
> If you can handle WebDAV why bother working with the AtomAPI at all? > > No really, I'm serious, if you can handle the complexity and server > requirements of WebDAV, then why do you need that AtomAPI? Choice of editing clients. Also, WebDAV is an extension to HTTP, one that is not necessary for a large proportion of Atom users. I bring this up because sometimes "use WebDAV" is used as the response for being able to PUT directly to a URI ("client controlled" as Joe referred to it earlier) rather than POST-only ("server controlled"). I'd like to point out that Atom-enabled servers are *always* in control. There's *nothing* a client can do that a server doesn't allow for. To me, the Atom API is less about "architecting" how servers and clients should be implemented than it is about a guide to using the web within a certain context to implement context-tailored servers and clients. I have a very strong concern about the Atom API not supporting web-enabled browsers/editors that can already PUT to the web, but not in the Atom XML Format. They are being *excluded* from this context *because* they are not tailored for this context. Yet it's still "just the web", or so I thought when we started down that road. -- Ken
* On the SnipSnap development wiki, the page "WebDAV" contains:
Someday, it would be keen if SnipSnap used WebDAV to present a filesystem interface, ala Blojsom, for manipulating snips and attachments. It's not obvious how to cope with metadata in this case, except to emulate FileSystemStorage.'' Perhaps WebDAV is an appropriate interface for managing attachments, while content management should be left to Atom.
* In a web column, RichSalz notes that:
What does the API do? According to the draft, "AtomAPI is an application level protocol for publishing and editing web resources..." Compare this to RFC 2518, HTTP Extensions for Distributed Authoring -- WEBDAV. According to the WebDAV FAQ: The stated goal of the WebDAV working group is (from the charter) to "define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs", and in this respect DAV is completing the original vision of the Web as a writable, collaborative medium. On the surface there seems to be a lot of overlap, but on closer inspection this isn't quite true. WebDAV spends a lot of time on locking, which is required for distributed authoring of the same document, but probably less germane to the single author/publisher model of a weblog. It's model of a collection nicely maps into a weblog entry and its comments, but it enforces a hierarchical syntax on the URLs which may not be always be possible or even desirable in weblog software. Finally, it defines a suite of HTTP extensions -- new verbs, new headers -- which also make the burden of implementation too great. Many weblogs are maintained using CGI scripts on an ISP; requiring such users to require a new web server (or at least a new Apache module) would immediately disenfranchise them from the new Feedster community. This last point -- the high barrier to involvement required by WebDAV -- runs so completely counter to Feedster (and its RSS history) that it alone is reason enough to discard it as an API. Still, WebDAV has some interesting ideas, and I hope that there are no gratuitous incompatibilities introduced, so that a future merge -- WebDAVLog? -- could be possible.
-
Note: the myth that new methods or headers require a new web server is covered in CarrotVsOrange.
* In comments to that article, MarkPilgrim responds,
The whole thing about WebDAV is confusing. Why would we want to try to be compatible with a protocol nobody uses?
* On the page EchoApiChangeLog can be found the following discussion:
-
[Dirk-Willem van Gulik] The discovery is a lovely addition. However from the spec it seems that a lot of the functionality is already in web DAV, and to some extend it feels like re-inventing the wheel within POST as to avoid existing verbs in HTTP, such as PUT, DELETE and DAVs versioning scheme. Also - some things may be better done 'out of band' - i.e. on HTTP header level, rather than overload the payload of HTTP itself with two types of 'data'. If the reasoning behind this is that _todays_ most popular webserver does not expose enough to PHP, CGI or Perl - then it may be easier to simply fix the web server to pass PUT/DEL, etc easier to cgi or the application langauge; openup DAV a bit more and make the headers more accessible.
-
[JoeGregorio] I have read the WebDAV specification and from my reading it looked like there was a substantial difference in the amount of functionality WebDAV offers over the EchoAPI. I would be interested in hearing how closely the two were aligned.
-
[Dirk-Willem van Gulik] Both have a basic set of verbs on a set of objects, where each is annotated with a chunk of 'metadata'. Having said that - WebDav is ABSOLUTELY not a replacement; it is just that it may be a larger stepping stone than HTTP for echo to stand on. For it to work it would need a set of concepts/rules or well-known anchor points to be defined. However, the total amount of work would be far smaller than when you start with just HTTP. Although I am a known sour septic when it comes to DAV, when I look at examples like subversion.tigris.org, which have a protocol option that run over DAV, then I grudgingly have to admit that it does seem to have absolutely right at least the basic atoms of any publishing/content management interface. It can cope with versioning and metadata about the content well enough.
-
[JoeGregorio] "some things may be better done 'out of band'" Are you talking about using custom headers? Is there someplace in particular you see this could be used?
-
[Dirk-Willem van Gulik] What I mean is that HTTP itself already has verbs and headers outside the MIME-encapsulated payload. Echo does not make that much use of such; but instead has its own content inside the mime payload inside the content payload of HTTP, hence the need to start escaping, etc. Or, in other words, Echo could be run over just about any other protocol, as long as it has a few very basic 'REST-ish' verbs. Which seems a shame, as it probably is only going to run over HTTP. This also seems a shame because Echo thus falls into the same trap as SOAP does - where the lowest common demoninator of the features of the transport layer force reinvention of features inside the application protocol, even for those cases where the transport protocol actually has those features; just to 'make SOAP not protocol bound'. So, maybe, it would be possible to separate on MIME level: for example, using multipart-mixed and for example separate metadata as well formed XML in one blob and the <content>..</content> blob in another; or even furter -extend the HTTP headers -or- use the PROPFIND http level separation to convey some of that data.
-
[JoeGregorio] The idea of further extending the HTTP headers, as a place to store some of the desired information is a very important point that needs to be kept in mind as the AtomAPI evolves.
* I believe that SamRuby was a member of the WebDAV Interim Working Group.
* From this article on JoeGregorio's site:
Sam, Re: PUT. I would be fascinated to hear your views on WebDAV, which you were involved in. Yes, WebDAV, which not only uses PUT and DELETE, but which also invented new HTTP status codes and also invented new HTTP verbs.
and SamRuby replies,
Short answer is that WebDAV has not taken the world by storm. But I will be taking a closer look again at it tomorrow... http://www.oscom.org/Conferences/Sprints/San%20Francisco%20September%202003.html Note the #2 name on that list can also be found on http://www.webdav.org/. And both of our names are on http://www.apache.org/foundation/board/
Discusssion on the relationship
You would think that this would be an FAQ, but I've searched the first ten pages of Atom+WebDAV, and the atom-syntax mailing list (as of Jan 31, '04), and I haven't found a comprehensive answer. I don't know much about web standards, but at first glance it seems that much of Atom concerns specifying the way for clients to remotely modify web resources, which is what WebDAV seems to do. So, why not just use WebDAV? Here are some potential (contradictory) answers that I came up with:
-
1. WebDAV and Atom do similar things. Use WebDAV if you can. But, some people are stuck on servers for which they don't have enough control to add WebDAV support. For them, we're writing the Atom API, which is like "WebDAV over CGI". Or, "Atom tries to 'work within the web'; WebDAV extends the web". (if this is the case, though, then why doesn't this wiki, and the API, loudly proclaim "IF YOU CAN USE WEBDAV, DO SO! OTHERWISE, STAY HERE." ? )
-
it seems that JoeGregorio thinks this (see above), and maybe RichSalz (see above)
-
2. WebDAV is a generic solution. Atom adds functionality specifically for weblogs. (if this is the case, though, why isn't there more talk of compatibility with WebDAV? Shouldn't Atom ideally be run on top of WebDAV, if its goal is to do the same thing, but with additional specialized functionality?)
-
it seems that SnipSnap thinks this (see above) (or at least HansGerwitz does)
-
3. Atom is a replacement for WebDAV. We can do better. (if this is the case, though, why not say so?)
-
perhaps SamRuby thinks this (see above)
-
4. Atom is designed to "work within the web", meaning, to be compatible with EXISTING tools, even tools which aren't quite Atom-aware (this is my interpretation of ParticleWave, and of some of KenMacLeod's comments elsewhere, although I may be misinterpreting). By contrast, in order to use WebDAV, a client definitely has to be WebDAV-aware. (but is this really a central goal of the Atom spec? Will Atom really achieve this either?)
-
perhaps KenMacLeod thinks this (see above)
-
5. Who cares about WebDAV? We don't believe that it's worth the effort to consider. (seems unlikely to be the case)
-
it seems like MarkPilgrim thinks this (see above)
-- BayleShanks
Another issue that I'm particularly interested in, in the context of AtomForWikis: WebDAV already has an extension to support versioning (DeltaV), and was designed with DistributedAuthorship in mind. This is a big plus for wikis.
-- BayleShanks
We need a simple, easy to understand protocol that is relatively light to implement, and works for 80% of the cases. I believe the analogy is the same as between XML-RPC and SOAP: the latter is complete, but quite heavy compared to the first one. It is being used in corporate environments, but the individual developer almost invariably uses XML-RPC because his needs are not that complex. Anyone who wants to implement a WebDAV client on Symbian on his spare time? Nobody? How about Atom?
I agree that WebDAV probably works better for Wikis - internally anyway. I've been thinking about WebDAV support to JSPWiki for some time now, and it would have some interesting potentials such as the ability to combine wiki repositories with things like JXTA autodiscovery....
Thought: many people say "WebDAV" when they really mean PUT. PUT is plain HTTP. WebDAV basically adds locking (cooperative collaboration), metadata (PROPFIND/PROPPATCH) and namespace considerations (collection containment, discovering children, MOVE/DELETE). Atom can probably do without all of this. As an author of WebDAV servers, I'd like the ATOM API to be inherently compatible with HTTP/PUT. Taking advantage of more WebDAV machinery would be interesting, but could easily happen in a separate spec, once implementers of WebDAV servers start considering native Atom support. Finally, for a protocol that "nobody uses", I see a surprising number of implementations. NIH syndrome?
-- Julian
Err, why do we assume that the server (infrastructure) needs to support WebDAV? It's perfectly possible to write a WebDAV server-side implementation entirely in CGI (I'm doing one now). If we need the semantics of COPY, MOVE, LOCK, MKCOL, PROPFIND, PROPPATCH, etc., it seems like a good idea to reuse what's there, rather than reinvent the wheel. That doesn't mean that we need to require support for everything in WebDAV, of course. It also doesn't mean that there can't be alternate interfaces as well.
See also an old blog entry regarding this.