WebDAV also follows the REST Architectural Style.

See also:

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:

* KenMacLeod responds:

* On the SnipSnap development wiki, the page "WebDAV" contains:

* In a [WWW]web column, RichSalz notes that:

* In comments to that article, MarkPilgrim responds,

* On the page EchoApiChangeLog can be found the following discussion:

* I believe that SamRuby was a member of the WebDAV Interim Working Group.

* From [WWW]this article on JoeGregorio's site:

and SamRuby replies,

Discusssion on the relationship

You would think that this would be an FAQ, but I've searched the first ten pages of [Google]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:

-- 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.... ;-)

-- JanneJalkanen

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 [WWW]an old blog entry regarding this.

-- MarkNottingham

CategoryArchitecture, CategoryTool, CategoryApi