0

I have a design dilemma in deciding the response status code and architecture for a middleware we are designing.

So the Client Calls MiddleWare, And middleware calls the 3rd party service to get car-values for a particular car-reg.

If everything goes right and we get car-value, we are sending the status code as 200.

But what if we did call out to 3rd party, we received 200 from them, but it did not have car-value that we want, shall we pass 200 status code back to the client or give a different status code.

The argument given by my middleware team to give 200, is its not an issue its just no data from 3rd party so status should be 200 and a status field in JSON response to tell, the values could not be found.

Which feels quite wrong, if I am client, If I don't get car values, how can it be 200 for me?

EDIT: It's a get request where I pass Car Reg in URL params, I want car value, so anything other than car value is kinda error or failed request for me?

Pranay Jaiswal
  • 137

2 Answers2

1

200 status code should adhere to the standardization specs. Your request was processed right, it's just that there's no value to be returned. There were no errors encountered along the way, so 4xx/5xx status codes shouldn't be thrown. As far as I know, even none of the funky/unofficial status codes are useful in this case, you might construct your own, but be sure to document it so that other devs know what to expect.

Milan Velebit
  • 507
0

From client's point of view, middleware is service provider or backend. And hence we should code as if middleware is the data/service provider. Based on this point of view:

When refering to firefox documents for http status code, Status code 204 seems to be most correct in this scenario, as the request is successful (to middleware and onwards), but no data to send back, empty response is there.

Aditya Ajmera
  • 1
  • 3