4

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"?

  • 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? – MetaFight Feb 5 '15 at 14:31
  • 1
    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. – Cormac Mulhall Feb 6 '15 at 18:17
  • @CormacMulhall This really should be an answer. It is much better than the currently accepted answer as that one condones breaking principles of REST – maple_shaft Feb 10 '15 at 13:08
2

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]

  • Yes, it was my first idea. But should I use 200 HTTP status code if some of "subrequests" have failed? – Ginden Feb 5 '15 at 14:34
  • I just edited the answer – RMalke Feb 5 '15 at 14:40
  • 3
    This smells of a fudged REST implementation. – MetaFight Feb 5 '15 at 15:02
  • If the server rejects the new state of the resource you should not return 200. If a 200 is returned this implies that the client and server now both have the resource in the exact same state. If that isn't true, because the server has rejected the new state (even if just a bit of it) then the server must return a 4xx error explaining to the client why it could not accept the new state. – Cormac Mulhall Feb 6 '15 at 18:26
  • 1
    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" – RMalke Feb 6 '15 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.