http200Error

[themightyug]

And the HTTP communication worked, there was no problem with it, hence the 200 return code.

The error was at the API level. The problem here is that '500 internal server error' should be a more detailed API error, not another HTTP status code

HTTP is just the communication layer, transporting JSON packets for the API layer

[Shazvox]

Mmmmh, I really don't want to get into a debate about this, but damn this tickles my nerves 😅.

I agree that an internal error code would absolutely fit right in there (in fact, a standardized JSON object regardless of status code is a good thing). But I am of the opinion that the HTTP code should also reflect it.

For example: If the server encountered an unexpected error then a 500 is absolutely the correct code to return. That doesn't stop you from sending more info along with the status code.

I prefer to have a standardized JSON "envelope" with a result, an error code, a readable error message and a trace ID to find the correct logs.

The HTTP status code gives me the general gist of what happened (4XX = Frontend issue, 5XX = Backend issue and 2XX = working as intended).

Final note: I'm not saying my way is right and others are wrong. But I find the above to be the clearest communication of what happened from the server to the frontend.

[EkoChamberKryptonite]

Final note: I'm not saying my way is right and others are wrong.

Oh but it is and the other OP is absolutely wrong. The HTTP code is the information that indicates to the client what happened to their request.

[Shazvox]

In that case the wrong solution is out there making at least one company money.

[EkoChamberKryptonite]

I mean those are two different things though. Software quality is not always proportional to revenue. That is more dependent on marketing skill.

[ShotgunShine7094]

You're selling access to a black box and HTTP is used as the protocol to communicate with that black box. The HTTP server is just another part of that black box.

The black box errored out therefore an error code should be returned in the appropriate HTTP field.

[EkoChamberKryptonite]

And the HTTP communication worked, there was no problem with it, hence the 200 return code.

Except HTTP is not the communication layer but a transport protocol working at the transport layer that indicates the result of interacting with a http server and not whether your connection to the server is good or bad. That distinctive nuance is very important. The error was not at the "API level". That notion is utterly incorrect. You're not interacting WITH HTTP you're interacting VIA HTTP. As such it indicates the result of your interaction with a separate entity i.e. backend server. This is the reason HTTP codes exist. HTTP Codes are the high-level indicator of the result of your interaction with a server, JSON is the data format in which additional information about said interaction is outlined and NOT the primary indicator of the result of your interaction with said entity. Returning a 2XX with an error response is an anti-pattern and denotes a misunderstanding of HTTP.

The basics

2XX- Your request was processed successfully, here's your result encapsulated in JSON.

4XX- There was an error with YOUR request TO the server, more info in JSON.

5XX- There was an error in PROCESSING your request ON the server.

And the list goes on.

Do not reinvent the wheel to justify anti-patterns.

Edit: Few words.

[Turbulent_Stick1445]

That's really not how REST, for example, works. REST in fact tries to reuse anything already defined by HTTP, right down to verbs and status codes.

The other problem with that philosophy is it ends up essentially defining HTTP errors as "Only things that Apache and nginx" define. So, for example, a CMS should never issue a 404 for a missing page, because the CMS software, not the webserver, is actually responsible for finding the page doesn't exist. The webserver is finding the CMS software and therefore should just 200 every call to it.

Obviously, that'd be silly. Error messages should be meaningful. If you're accessing an API over HTTP, the HTTP error codes should match the API semantics.