"200 Internal Server Error"

Yep, I did that. Because the lousy crapheads I work with were too lazy to handle any other HTTP status so anything else breaks the whole thing. And it's a pain to roll out another release of their part of the backend so "this isn't a priority". Also, they don't feel the need to check the JSON body of the response for the "status":"ok"/"fail" because what could ever go wrong, right? I effectively have no way of conveying to them that there was an error on this end of the API so they show success toast on the frontend irrespective of what really happened.

  • 5
    in my case, our infosec department wants all status to be 200 series and their reason is to mislead hackers that whatever the f* they'll do to the system, it will always be OK.
  • 3
    sounds like you need to hire new front-end devs...
  • 3
  • 2
    If the crapheads can’t do their job, make their life miserable.
    They’ll either work it out or never deliver anything.
  • 2
    Well, Internal Server Error is usualy reserved for unhandled exceptions and should be returned by server/api and not your code. And as far as I know, it's okay to return a 200 with an error body if the frontend can handle it. It's like returning Not Found when your search query didn't find anything. It can be confusing. Then you start wondering if the Not Found was returned because you have a bad api route or did your search didn't find anything. At least that's the way I see it.
  • 1
    @Aedath yeah, it is only returned when either we're really screwed or unhandled stuff. But this was mainly for demonstration purpose, I also send 200 Bad request and 200 Forbidden
Add Comment