rishabhpoddar
commented
11 months ago We are aware about this issue, whilst it may be inconvenient, it's not broken. However, we recognise that this is not RESTfull and can be unintuitive and annoying for devs - we will eventually fix it when we finish our current roadmap of features.
The motivation for doing this in the first place was to distinguish between expected and non expected errors. Expected errors are due to user input mistakes (like entering a password that doesn't match the password policy during signup) vs unexpected errors are due to system failures like the db going down. 400 errors should only arise due to programming mistakes like not providing all required inputs to an API.
The reason to distinguish between expected and unexpected errors is in how devs can handle these. Expected errors need to be handled gracefully - usually by showing a specific error message to the end user. Whereas unexpected errors can show a generic something went wrong. In order to make this distinction clearer to devs, we had originally decided to follow this pattern.
Thanks for raising this issue.
Why do you return 200 HTTP code on errors? For example: when you check the validity of an email, if email is invalid "Email is invalid", you return the code GeneralError + 200. This is not RESTfull and not convenient, because in other places you sometimes return 400.