HTTP Status Codes - Partial FAILURES

[prem]

Hi Everyone,

  Like to know thoughts on the below.

   Have a rest ful webservice which does a bulk enrollment. (accepts 50 user request elements and inserts them in a DB). Based on  business requirements  we do not want to reject the transaction because of  1 or 2  failures encountered  during the insert.

  So there could be a potentially partial failures (48 successfully inserted 2 error ed because of some reason).

  in this case what would be a better http code  , to let the client know that the response body has a partially failed response.

  Please let me know 

Thanks

Prem

[Jack Repenning]

On Apr 2, 2012, at 12:02 PM, prem wrote:

  So there could be a potentially partial failures (48 successfully inserted 2 error ed because of some reason).

  in this case what would be a better http code  , to let the client know that the response body has a partially failed response.

Uh ... "push back on the business requirement"? No, sorry, that just slipped out ;-)

There is a status 207 "Multi-Status," that allows your body to contain a list of status values, so you'd be able to say which ones succeeded or failed. It is, however, a part of WebDAV (distributed versioning, like Subversion or Git), not basic HTTP, which probably makes it too arcane for REST use. If you must go bravely into that good night, check RFC 4918 for further details.

Jack Repenning

No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication-applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence.

--ALGOL 68 Report

[Carlos Eberhardt]

Is this a nice spot to model a transactions collection for enrollment? Post to it, return a 201 created. The returned resource for the transaction could contain details on success/failure?

Thanks,
Carlos

[Daniel Roop]

At my office we have separated the concept of Transaction and Bulk.  The two seem very similar, but the way we draw the distinction is a transaction either passes or fails, but a bulk operation can be partially successful (or failed).  The scenario you are describing we would categorize as a bulk action, and we actually defined a very generic way to submit these based on underlying resources.

In our case, since our bulk action is a description of underlying behaviors, we chose to return a 200, because the bulk operation worked, but the client is then expected to interpret the results to find out the details of each individual action.

In another case a client is requesting something to happen say for instance retrieve details about a dog.  Let's say the dog resource is an aggregation of data from two backend systems.  From a resiliency perspective some clients may want to get back the resource even if only one of the backend systems is up.  We define this "partial-success" as part of the API specification that client should conform to/expect, and use our standard error structure to state there was a partial-success.

{

    "name" : "Buffy",

    "bread" : "Pomeranian"

    ...standard response properties...

   "errors" : [

       {

          "typeId" : "PARTIAL_SUCCESS",

          "description" : "One or more of the actions in this bulk request failed"

       },

       {

           "typeId" : "MISSING_PROPERTIES",

           "fields" : ["weight", "sex"]

       }

   ]

}

And then in some circumstances we add addition error objects within the response, to state more clearly what went wrong.

So I guess to answer your question, we use 200, for the type of operation you are talking about, and consider the error handling part of the application protocol not part of the transfer protocol.  That being said we would prefer a 2XX level error response to specify this state, so we could more easily track it at the transfer protocol level.  We looked at 206, but didn't feel quite right, I hadn't see 207, but since it is intended for webdav, not sure I would go that route.

[prem]

Thanks Everyone..so i understand there is no standard as i am trying to combine multiple units of work in a single request. Will try the suggestions.. Thanks