Re: Prefer Draft Feedback

Yeah, this is an item that's still somewhat up in the air. The main
challenge is that when sending "Prefer: return-status" or "Prefer:
return-representation" (yes, Julian, if you're reading, I went ahead
and renamed it.. you were right it did make more sense that way)...
it's generally impossible to reliably determine which type of response
you're getting back. There's absolutely nothing in the response I can
key off of to determine whether the entity is a representation of the
resource or a representation of the request status. The idea here was
to use the presence of the Content-Location header as that key. If
Content-Location is in the response, then I would assume that it's a
representation of the resource, otherwise, I have to assume it's a
status. This is definitely far from perfect, obviously, but it aligns
with the behavior of apis based on the Atom protocol and a few others
I have seen. However, ideally, there would be some explicit signaling
mechanism that I could use without having to abuse Content-Location in
this way.

On Tue, Dec 6, 2011 at 8:38 AM, Moore, Jonathan (CIM)
<Jonathan_Moore@comcast.com> wrote:
> On 12/5/11 7:32 PM, "James Snell" <jasnell@gmail.com> wrote:
>> http://tools.ietf.org/html/draft-snell-http-prefer-05
> Hi James,
>
> I had a question about the following recommendation:
>
>> When honoring the "return-status" preference, the server SHOULD NOT
>> include a Content-Location header field in the response.
>
>
> What if the status has its own URI, to be used for polling the status of a
> long-running job, for example? Wouldn't it be appropriate to provide this
> URI in a Content-Location header on the response?
>
> Jon
>
> ........
> Jon Moore
> Comcast Interactive Media
>
>

Received on Tuesday, 6 December 2011 18:48:39 UTC