Let's be honest and real, I'm sure that I'm not the only one experiencing this.
Are you or your co-worker, especially the backend developer, made all the responses always to be 200 even though it returns an error message like the server's internal error or the client's validation error?
What is your or their intention to make it that way? while there are standardized and appropriate http codes for specific cases out there.
If you wonder how to find these http codes and their respective meaning, I use the symfony http foundation as reference: Symfony HTTP Foundation component
cover image from: https://www.youtube.com/watch?v=nSKp2StlS6s
Top comments (7)
Facebook's API used to return 200s for everything!
Sometimes the focus on the API isn't on semantics, but just volume of data, or they're just very opinionated about how they want to surface errors to users (not semantically)
I do like a semantic API. Most of our APIs are semantic now, but some legacy ones return 200s with error codes, while we're working to phase them out.
Wow, I didn't know that since I haven't used Facebook API before. Maybe this phenomenon takes a big part in influencing these peoples 😮
Yes, legacy ones should make sense if it still likes that. But in my experience of working in a small to medium companies level in my country, I still find they use
200 OKeverywhere.If there is anyone who follows the standardized HTTP responses around me, I would be impressed.
When I used to architect and build APIs, I'd follow the Richardson Maturity Model: martinfowler.com/articles/richards...
It's always better to start small and work up, while returning 200 with an error is never okay, a better primer is a short guide on the most important client error status codes
I'd wager that it's generally either lack of knowledge and/or lack of motivation, since it's somewhat easier to just add an 'errorMessage' to the DTO and be done with it.
Yes, my assumption is the same as yours. It's either the backend doesn't know how to do it or the frontend doesn't know how to use it. But mostly I believe it's on the backend team.
Generally speaking, it's the backend team that makes the API, so then it can only be the backend team that makes that choice. Except of course when the API design is something that has been dictated to them, and isn't open for discussion and improvement. That can unfortunately sometimes be the case.