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

On Dec 5, 2011, at 6:46 PM, Markus Lanthaler wrote:

> Hi,
>  
> First of all sorry for the cross-post, but I wasn’t sure where to send it.
>  
> I've just stumbled across the "draft-nottingham-http-new-status" ID and was wondering whether you considered to include a status code for partially fulfilled requests. It is not unusual that a request can be considered as successful even if it couldn't be fulfilled completely.
>  
> A purchase order, for example, could still be created even though not all order items are available for order. The client can then revoke his order or proceed with the checkout without having to place another order and risking that other items get unavailable (think of ticketing where you often have the possibility to reserve tickets for some minutes).
>  
> This would reduce the number of required round-trips and potential "lost update" problems.

When extending HTTP status codes, the question that needs to be asked
is "how will a client process this response differently than any of
the existing status codes?"

In particular, a "partially fulfilled request" can only occur with
POST and some of the depth-altering WebDAV methods.

For POST, this response is no different than 200 -- the client has no
idea what semantics are provided by the service and thus cannot
differentiate partial from complete success without the service
telling the client what to do next (i.e., exactly what 200 does).

For WebDAV, they defined 207 (and utter pain follows thereafter).

IMO, HTTP should avoid introducing partial failure conditions as
if that were a reasonable response.  Non-atomic services can be
redesigned as atomic services far easier than deploying clients
that can recover from arbitrary partial failures.

....Roy

Received on Wednesday, 7 December 2011 00:44:51 UTC