Re: Partially fulfilled / draft-nottingham-http-new-status

On Tue, Dec 6, 2011 at 4:44 PM, Alex Rousskov <
rousskov@measurement-factory.com> wrote:

> On 12/05/2011 10:46 PM, Markus Lanthaler wrote:
>
> > It is not unusual that a request can be considered as successful even
> > if it couldn't be fulfilled completely.
>
> ...
>
> > I think such a behaviour would be very important in evolving systems. As
> far
> > as I know, there are currently only two ways to deal with it: either
> process
> > the request and return a 200 OK signalling everything was OK or ignoring
> the
> > request and returning a 400 Bad Request.
>
> A third way would be to return a 200 OK response with an extension
> response header or custom body that indicates which parts of the request
> were not "fully fulfilled".
>
> A forth way would be to include extension request headers or custom body
> pieces indicating client preferences with regard to considering
> partially fulfilled requests successful.
>
>
> >From HTTP point of view, 200 OK seems like an appropriate response here
> because the transaction went through and the HTTP server considered it a
> success. The application-level details of that success can be left to
> the extension headers or body.
>
> A user-agent receiving just a "partially fulfilled" status code is
> likely to want a lot more information anyway, resulting in the
> additional requests you wanted to avoid. For example, a purchase
> order-placing agent would want to know which items were not ordered
> before deciding whether to revoke the partial order.
>

Agreed — if you're going to have to define a custom format anyway (as you
are in almost every case) then you're probably better off just using
existing codes.

"202 Accepted" applies to any state up to (but not including) completion,
so it's not really appropriate for synchronous requests, while "200 OK"
specifically allows for "an entity describing or containing the result of
the action".

That said, as I'm busy applying HTTP (as it was intended rather than with
envelope layers) to cloud standards I find myself regularly wanting to give
status updates — as x of y units, %, etc. — and it could be useful to have
a header that carried this information in a sensible/standard format. A
marked up Link: to a [text/uri-]list of components could be interesting too.

Sam