3

USE-CASE: I am designing an update API where the external clients can pass the resource information (in JSON format) to persist. The whole resource is persisted into multiple downstreams(parallely) in form of smaller resources. So, if any one downstream is down, I plan to return 5XX http response code to make sure the client retries. But at the same time want to make sure the client is aware of what part of the resource was successful.

I looked into other similar questions (Q1, Q2) about HTTP response code as 207 and 202 but they are not applicable to my use-case as this is not a batch request and the full resource is can be divided into smaller resources for the external clients. From my understanding, 202 is applicable for async processing scenarios where we were able to accept the request and are still processing whereas in my case, I want to make sure the client knows that the request failed and he should retry.

APPROACH BEING CONSIDERED I plan to return HTTP response code as 5XX but at the same time will add the part of the resource (JSON format) to the response that was successful.

I would like to know if the above mentioned approach is accepted from an industry standard and if anyone has solved such use-case.

Keen Sage
  • 1,899
  • 5
  • 26
  • 44
  • Most of the front-end libraries / frameworks will consider 5XX as error and the response will land up in error handling code. So, their is no point of providing partial response with error code 5XX. – Atul Sharma Dec 03 '18 at 17:18

1 Answers1

0

Honestly, you already talk about sub-resources, partial successes and being able to retry the ones that failed. All of these features are perfectly available in HTTP and will work extremely well, if you just take one more step: split up the request into multiple requests.

Evert
  • 93,428
  • 18
  • 118
  • 189