0
votes

I have an internal API (A) which connects to 3rd party API (B).

API B can give below errors

  1. ERR001
  2. ERR002

API A has a error message configured for the same error code as below,

  1. ERR001 - Error1 occurred
  2. ERR002 - Error2 occurred

Now API A returns below incase of any error/exception

Response headers : HTTP/1.1 500 Internal Server Error
Response Body: {"time":"2000-04-..","errors":[{"code":"ERR001","message":"Error1 occurred"}],"details":"uri=/*","status":500}

Does setting up error status HTTP/1.1 500 Internal Server Error is more suitable for this situation?

Does wrapping the known error code as 500 status is good Idea?

If not which status code should i need to set and can i keep the same error structure?

2

2 Answers

0
votes

Does setting up error status HTTP/1.1 500 Internal Server Error is more suitable for this situation?

I would say, YES.

Because in many cases (Or what I think) you should not expose what error occurred while communicating to the third party libraries.

Does wrapping the known error code as 500 status is good Idea?

It depends.

If the error is occurring in your application because of some business logic.In that case you should throw some clear error code and error message.

But if the error is occurring because some 3rd party library fails, in that case you should not throw exact error message. Because it can be secret information.

0
votes

You will get 500 even if you don't do anything, if something fails in the server and its not handled then the server would automatically throw 500. It would be better to return other status codes to differentiate between an exception that you have handled, the reason being that if you see 500 you will know that its something that you have not handled.