6

I am working on a use case where I have a dependency on a downstream API. The issue is that a single resource for me is made up of multiple resources for the downstream service. So a single write to my API may be internally multiple calls to the external service and any one of those calls may fail.

In the case of everything being good I am returning a 200 OK empty response and in the case of an invalid request or server error I am returning a separate error response. What should I return in the case of partial success? I am aware of the 207 Multi-status response code but am not sure if that is applicable here since that looks like it's more applicable to a batch operation. A 207 response with a list of failed sub entities looks like the best bet as of now. Any ideas of a more cleaner way would be appreciated.

Chakkakuru
  • 87
  • 1
  • 1
  • 8
  • Do you return anything in the body of the response? Or is your client only interested in the HTTP status code? –  May 28 '15 at 06:36
  • In this particular case, there is nothing to return in the case of a full success. Ideally, I would want a general enough model to cover the three cases 1. Full Success 2. Partial Success and 3. Client/Server error – Chakkakuru May 28 '15 at 07:24

1 Answers1

2

This was more sort of a design choice so finally I went with the following response model 1. Success - 200 OK with applicable body 2. Partial success - 200 OK with applicable body plus warnings 3. Failure(4xx/5xx) - errors body listing the errors

Chakkakuru
  • 87
  • 1
  • 1
  • 8
  • There's this [answer](http://stackoverflow.com/a/8474782/2429640) that say you should use 207 status code. I don't know, it might still be worth to check it. – ldavid Sep 06 '15 at 01:22
  • Like I said in my question, that I considered 207 but did not go with it since it looked more suitable for a multi-entity batch request. I went with this model instead. – Chakkakuru Mar 28 '16 at 20:02