Comments on: WebDAV and POST https://quoderat.megginson.com/2013/04/11/webdav-and-post/ Open information and technology. Fri, 12 Apr 2013 18:49:02 +0000 hourly 1 http://wordpress.com/ By: Hello https://quoderat.megginson.com/2013/04/11/webdav-and-post/#comment-4264 Fri, 12 Apr 2013 18:49:02 +0000 http://quoderat.megginson.com/?p=651#comment-4264 If you’re expecting to upload a new file, you do a conditional PUT. The pre-condition will fail if some one else beets you to it.

]]> By: David Megginson https://quoderat.megginson.com/2013/04/11/webdav-and-post/#comment-4259 Fri, 12 Apr 2013 15:10:50 +0000 http://quoderat.megginson.com/?p=651#comment-4259 That’s a good, clear distinction, John, and it will help me decide which use cases do or don’t lead to WebDAV as a solution.

]]> By: John Cowan https://quoderat.megginson.com/2013/04/11/webdav-and-post/#comment-4257 Fri, 12 Apr 2013 01:24:19 +0000 http://quoderat.megginson.com/?p=651#comment-4257 The reason WebDAV doesn’t provide what you want is that it is a file-server protocol like FTP, which assumes that the client is in control of the names used on the file space. When you write a file to some network drive, you are expected to specify the name it will have on that drive. If someone else has already written a file with that name, tant pis — and if someone else comes along and writes a file with that same name after you, you lose.

In general, the model of POST, when properly used in a REST style, is that the server makes up the URL of the new entry and tells the client about it. There is nothing to prevent the client from providing a hint, but I don’t think it makes sense for the hint to be in the URL itself. Rather the URL should point to a container where the new object will reside, and you’ll get back an extended URL specifying the new object’s server-created name appended to the container URL.

]]>