Re: server applying PUT to a resource other than the request-URI

Roy T. Fielding wrote:
>> So, should AtomPub have required support for PUT-to-create? (trying to understand what you're saying...)
>
> AtomPub requires HTTP.  HTTP already defined PUT.  There is no need
> to define what has already been defined.  AtomPub needed to define what
> its link relations meant, not what the response to POST meant.

Yes.

>>> 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
>>
>> Yes. So what is the best way to do that?
>
> Use an element that says: POST to this URI if you want to do X.

As a matter of fact, that was what I proposed.

>> That's true, but I don't think this is the use case I was interested in.
>>
>>> 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.
>>
>> Of course a redirect needs to be a 3xx.
>
> Sorry, I meant 301.  307 is only for temporary redirects.

But in this case a temporary redirect is actually needed. If the client gets a 301, it potentially use the URI given in Location: for all subsequent request, and that's definitively not what people want in this case.

> ...
>> I would have thought that a 4xx status code such as 405 Method Not Allowed (server does understand PUT, but not on this URI) or 409 Conflict (current state of the resource conflicts with the request) would be adequate?
>
> It might be.  It largely depends on what you consider to be adequate,
> whether you want the client to offer redirection to the user, and if
> the client properly displays the body of the response to explain
> what just occurred.  Each response gives the client some idea of how
> (or if) the problem can be fixed.  The only fix that can be automated
> is the one for 301, which is why that is defined in a way that can
> be automated (if the user agrees or has preconfigured their client
> to follow that redirect).
>
> Personally, I would code the server to accept the resource as defined
> by the client and then create a 302 binding for the slug URI.  But
> that's just me.  There is no single way to do this in HTTP and there
> is no need for one because the response tells you what worked.

That approach would work, but still requires the server to persist the names chosen by the client. I'm not saying this is bad, but it was the claim that some servers couldn't do that started this discussion.

Right now some work around their problem by accepting the PUT (with 201), but storing the resource under a different URI, and it seems to me that this a bad idea (given the PUT semantics defined in HTTP).

BR, Julian


-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Received on Thursday, 23 October 2008 07:01:30 UTC