- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 21 Oct 2008 08:29:36 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Oct 20, 2008, at 11:39 AM, Julian Reschke wrote: > Of course that's not going to work in practice, as Cyrus pointed > out. We want to help servers that generate the URL based on the > underlying persistence, so the server really can't predict the > final URL until the resource is created. No, we don't want to help those servers. Why help bad design? The whole premise of this question is just silly. If the server doesn't intend to support PUT on a given URI, then it won't be allowing PUT on that URI in the first place; it will be directing the client to POST. If the server actually does accept PUT on a given URI and is simply creating aliases for other things (like Slug-based permalinks), then that doesn't need to be noted in the response -- both resources still exist, both allow PUT, and the fact that one's state overlaps with another is simply irrelevant to the protocol. The answer is that if PUT is used and the server needs to redirect the request, then redirect with 307. Any other response in that case is not compliant with HTTP. If the server doesn't want that to happen then it will offer a POST interface instead, just like the spec says. ....Roy
Received on Tuesday, 21 October 2008 15:30:16 UTC