Trying to process partial POST of data in REST when some data is successful?

Question

I have a resource that accepts array of numbers. Each number is proceed interdependently, and computation fails are expected. How should I communicate to API client "some of your numbers couldn't be proceed, but rest was successfully forwarded"?

• MetaFight: I think it depends on how you access the resource and the structure of the resource itself. Can you include a bit more detail? Such as which verb you are using, the structure of the resource, and the nature of the partial failure?
• Cormac Mulhall: You shouldn't. REST is stateless, each request is independent of the last and the next. If you are updating a resource to a new state that update should not depend on a previous request. If that update fails because the server will not allow the resource to be put into the state the client has put it in then return a 403 explaining why the server has forbidden that new state.
• maple_shaft: @CormacMulhall This really should be an answer. It is much better than the currently accepted answer as that one condones breaking principles of REST

Answer 1

It seems the most straightforward method is just returning a XML or JSON, with the numbers and status.

Per your description, I imagine a structure like this would suffice:

{
 requestDate: '2015-02-05 12:32'
 results: [{
 number: 1,
 status: 'forwarded',
 },
 {
 number: 2,
 status: 'forwarded',
 },
 {
 number: 3,
 status: 'fail',
 }]
}

I also think a HTTP Status of 200 is most indicated, as the client request was successfully processed. Also you can read in the spec (emphasis mine):

10.2.1 200 OK

...

POST an entity describing or containing the result of the action;

Edit: Researching a little more about the status codes, I think it may be better to use 207 Multi-Status:

The message body that follows is an XML message and can contain a number of separate response codes, depending on how many sub-requests were made.[4]

• Ginden: Yes, it was my first idea. But should I use 200 HTTP status code if some of "subrequests" have failed?
• RMalke: I just edited the answer
• MetaFight: This smells of a fudged REST implementation.
• RMalke: I disagree about the 4xx, it is for client errors, per the description of the OP, is appear to be a problems with the server proccess. Maybe it would be more indicated to use a "207 Multi-Status"
• Cormac Mulhall: Depends on what caused the error. If the client is trying to put resource into a state the server won't allow due to an expected rule on the servers side then that is a 4xx since the client is making mistake. But yes if the server is having unexpected error that is a 5xx. Planning to have an unexpected error though is bad design.