[thelist] HTTP Response for "not ready"

[Benjamin Hawkes-Lewis]

On Mon, Jan 2, 2012 at 10:26 AM, Bill Moseley <moseley at hank.org> wrote:
> I POST a new resource and get back a 201 Created with a Location: header of
> the new resource.  That is:
>
> POST /widget  { <widget data> }
>
> 201 Created
> Location: http://example.com/widget/12345
>
>
> I can then later GET /widget/12345 and fetch that widget back.
>
> But, there's a period of time between the POST and the GET when the new
> resource is not ready.  For example, the resource might have been created
> (i.e. we know its new ID) but there's some background processing that must
> be done.  (I suppose 202 Accepted might be more accurate, but a 202 doesn't
> return the Location, IIRC, and doesn't even guarantee that it will every be
> created.
>
> This post<http://stackoverflow.com/questions/6144164/what-http-code-should-rest-return-for-a-resource-that-is-not-ready-after-a-202-c>
> mentioned
> returning a Location where to check the status but in this case I really
> need to return the location of the resource itself.
>
> I'd like to return some non-200 status code to indicate that the resource
> exists, but is not ready.  Is that appropriate[1] and what code would you
> use?

You could just include the expected location of the created resource
in the message body (entity) returned with 202.

What happens when a client requests a URL for a resource that is not "ready"?

Why not create the resource in an initial state, 201 to it, and then
update the resource on the basis of background processing later?

--
Benjamin Hawkes-Lewis