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

Roy T. Fielding wrote:
> 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?

So, should AtomPub have required support for PUT-to-create? (trying to 
understand what you're saying...)

> 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?

> 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.

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.

The question I'm interested in is: if a server behaves similar to an 
AtomPub server, in that new entries need to be POSTed to a collection 
URI, but can be updated using PUT on the individual resource URIs, what 
is the best behavior for the case where the client *tries* a PUT on an 
unmapped URI?

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?

BR, Julian

Received on Tuesday, 21 October 2008 15:42:57 UTC