Assuming I have a RESTful service and it always responds in this format:{    error: {         code: ...,        message: ...    }}or{    data: ...}and there is a method like POST /users/me/change-password.What would be the correct and RESTful behavior:Business logic / validation errors are dataPassword has been changed (200, empty error and data)User is not authenticated (401, error = 1, empty data}Password policy: password has already been used (200, empty error, data = 1)Password policy: password doesn't match requirements (200, empty error, data = 2)SMS-OTP confirmation required (200, empty error, data = 3)Incorrect SMS-OTP (200, empty error, data = 4)The user has disabled password changing (200, empty error, data = 5)It seems correct since errors like SMS-OTP confirmation required are not even client errors. A client did nothing wrong, and expects an OK response.Business logic / validation results are errorsPassword has been changed (200, empty error and data)User is not authenticated (401, error = 1, empty data}Password policy: password has already been used (400, error = 2, empty data)Password policy: password doesn't match requirements (400, error = 3, empty data)SMS-OTP confirmation required (400, error = 4, empty data)Incorrect SMS-OTP (400, error = 5, empty data)The user has disabled password changing (400, error = 6, empty data)It seems correct since 200 OK status suggests that password has been changed succesfully, whatever written in response. However, some clients like C# WebClient do not even return non-OK responses, they just throw exceptions.The same questions arise in terms of all authentication requests. For example, is username is already occupied for sign-in an error or data.
Should failed results be errors or data in RESTFul?
rest;api;error messages