Mention comparison with WebDAV in the introduction

[michielbdejong]

Many readers are confused why we chose to use a simple JSON-based folder description instead of reusing WebDAV which already provides XML-based folder descriptions. We should dedicate some words about this somewhere in the intro.

[michielbdejong]

We get the question about WebDAV a lot, in the next version we should add a remark about it in the intro. The folder descriptions returned when you GET a URL that ends with a / are indeed a deviation from the XML returned by WebDAV server, and this is just because nowadays JSON is easier to use than XML for developers, both client-side and server-side.

The fact that we don't require servers to support WebDAV's custom verbs like PROPPATCH etc. is for three reasons:

1. it's a lot of work to implement this without using an existing WebDAV library
2. in practice, a lot of WebDAV servers get it wrong, or don't implement all of WebDAV. It's very annoying for client implementers to have to deal with servers that e.g. chose not to implement LOCK and UNLOCK.
3. we don't really need all these advanced features on top of standard HTTP, just supporting GET/PUT/DELETE for resources, and adding a simple folder description format, is enough for most applications.

Other than that, the remoteStorage Internet-Draft specifies a lot more than just how each HTTP verb should behave:

• requiring support for OAuth implicit-grant flow
• requiring ETag support and nested versioning (i.e. the folder's ETag changes if anything within that folder changes)
• requiring CORS headers
• requiring a WebFinger announcement for service discovery

It would be easy to add these three things on top of WebDAV, instead of putting them on top of our minimal GET/PUT/DELETE API definition. In fact, we could probably separate it into two Internet-Drafts: one for the 'RESTful folders' API which is our simplification of WebDAV, and a second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful folders' or whatever other HTTP-based API you want.

[raucao]

It would be easy to add these three things on top of WebDAV, instead of putting them on top of our minimal GET/PUT/DELETE API definition. In fact, we could probably separate it into two Internet-Drafts: one for the 'RESTful folders' API which is our simplification of WebDAV, and a second one for OAuth/ETags/CORS/WebFinger on top of either WebDAV or 'RESTful folders' or whatever other HTTP-based API you want.

Releasing a new storage API for the Web using XML in 2015 would sure provide some good entertainment value. :)

Here's some more inspiration on WebDAV being too complex for its own good (a bit heavy on the ranting, but good content nonetheless): https://unterwaditzer.net/2015/kill-webdav.html

[ghost]

The obvious response you'll get will be why not define a simple profile for WebDAV, add CORS (trivial) add Bearer (trivial) and do something with ETags (maybe not so trivial, but also not relevant for every use case...).

Actually the spec does not require OAuth/Bearer tokens at all, also Kerberos. And don't get me started on WebFinger ;)

[raucao]

Actually the spec does not require OAuth/Bearer tokens at all, also Kerberos.

That is an allowed edge case for enterprise/organization usage, but not the normal case or recommendation.