I have an endpoint in API 1 (my api) that queries API 2 (another companies api) to view and edit objects stored in API 2’s database. API 1 is essentially acting as a wrapper service around API 2, providing some extra functionality.
If a call to API 2 within API 1 ends up with a 404 being returned (in my case because an object is still provisioning in the background) then should this 404 from the sub API call be passed back to the user? The request is correct, from their end they have made no mistakes other than maybe being a little too quick off the draw with calling endpoints on API 1 so soon after the object creation.
Especially in this case where the object DOES exist, but some of the metadata that might be required for the call doesn’t exist so that part 404s. At the moment this 404 error is being packaged up in a 500, but I’m not 100% sure this is correct.
5xx is for server errors, that is for situations where your server is malfunctioning. You could return 500 if you called another server that is guaranteed to never, ever return 404 – but it does, so your system is malfunctioning.
If the server that you called correctly returned 404 then that is what your server should return.
But there is another problem: Apparently you get status 404 when an object will be there very soon but isn’t quite there yet. If this is at all possible (and doesn’t take too long) it might be better to wait a little bit and return the object with status 200.