Status code: 200
Content-Type: application/json
Body: {"error": true, "responseCode":400 }

Classic

So logical. I don't see anything wrong with it 😒

@DanijelH yeah it could be a status from another REST endpoint. 🤔

@diobert I was being sarcastic but yeah, we don't know the context of the story 😄

Haha I had exactly that when I joined a new company.

This one's quite advanced though, it uses a boolean response for error and not a string "true" 😒

:@ our backend used to have this all the time. Instead of returning the correct result, it was stored in the object and the returning status code was 200. Drives you nuts when coding angular and error results keep taking the success path!

This fuckin happened to us today. A fuckin API that we were fuckin using in our fuckin application, fuckin did this fuckin blunder.

Hey at least the content type is ok...

My previous n+1 did the same shit on a previous project. The reason was "I don't want to mix network errors and application errors".

After 20years, the guy didn't know that HTTP codes ARE application errors.

Another story with the guy : https://devrant.com/rants/1440059/...

devRant API uses something like that. (Success = true/ false)

Found in the wild

Status: 200
Body: {"success": true, "message": "otp sent successfully to your number xxxxxxx", "otp": "1234"}

This is actually the recommended way of doing REST API responses. Twillio, Facebook and many others use this.

@Braed it's not the reccomend way, it's reccomend to use correct HTTP status codes

@AL1L then why do many of the largest online services do it that way?

@Braed because their big and believe they can do whatever they want. I said it was recommended, not required.

Why would there be status codes if you weren't recommend to use them?

@AL1L because its easier for the api consumer to just support a handful of codes (200,400,401,404,500) than all of them.
It's a controversial topic... This is worth a read:
https://softwareengineering.stackexchange.com/...

@Braed That question/answer makes sense.

I'm still going to use status codes + showing it in the body because it just makes things easier for me when making applications that use my APIs.