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

On Oct 21, 2008, at 8:42 AM, Julian Reschke wrote:
> 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...)

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.

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

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

Sorry, I meant 301.  307 is only for temporary redirects.

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

The best behavior is already defined by HTTP -- respond accordingly.

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

....Roy

Received on Wednesday, 22 October 2008 11:05:01 UTC