WebDAV vs REST

184 views
Skip to first unread message

miqui

unread,
Nov 11, 2020, 5:10:50 PM11/11/20
to API Craft
hi Community,

..if i am designing REST APIs, should i consider using HTTP status codes from the WebDAV specification? i know that REST is a style and while not trying to be a "Restafarian", ..but am not dealing exactly with WebDAV.

..thanks..

Erik Wilde

unread,
Nov 11, 2020, 5:16:37 PM11/11/20
to api-...@googlegroups.com, miqui
hello.

On 2020-11-11 23:10, miqui wrote:
> ..if i am designing REST APIs, should i consider using HTTP status codes
> from the WebDAV specification? i know that REST is a style and while not
> trying to be a "Restafarian", ..but am not dealing exactly with WebDAV.

http://webconcepts.info/concepts/http-status-code/ are "HTTP status
codes", which means that all of these apply to HTTP scenarios. WebDAV
may have added some that are a bit specific or odd, but that's more
historical than anything else. if you think you found one that's useful
in your scenario, jut go ahead and use it.

cheers,

dret.

--
erik wilde | mailto:erik....@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |

miqui

unread,
Nov 11, 2020, 5:33:49 PM11/11/20
to API Craft
..thanks Erik....  

so...
>>  if you think you found one that's useful
in your scenario, jut go ahead and use it. 
>>
...i can just take what the http status stands for,  424 "Failed dependency" <--- and ignore the actual WebDav semantics described in the WebDav RFC?

..thanks..
Miguel 

Erik Wilde

unread,
Nov 11, 2020, 9:12:02 PM11/11/20
to api-...@googlegroups.com, miqui
hello.

On 2020-11-11 23:33, miqui wrote:
> >>  if you think you found one that's useful
> in your scenario, jut go ahead and use it.
> ...i can just take what the http status stands for,  424 "Failed
> dependency" <--- and ignore the actual WebDav semantics described in the
> WebDav RFC?

it's unfortunate that there was a period when these things were simply
accepted into the registry, instead of making sure that WebDAV didn't do
uch a bad job at registering reusable HTTP parameters. anyway, it's
better these days, but that's a different story.

the proper way would be to update these entries like @jasnell is
currently doing for the SEARCH method:

https://tools.ietf.org/html/draft-snell-search-method-02

but i'd say it still would be not-so-terrible to ignore the WebDAV
practices and assume things were defined in a more reusable way.

if anybody is interested in working on a draft to do that cleanup, let
me know. the new HTTP building blocks WG would be a most excellent place
to help with this kind of effort. /cc @darrelmiller
Reply all
Reply to author
Forward
0 new messages