Skip to content

Not standardized response on error #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ramoncardena opened this issue Dec 1, 2018 · 4 comments
Closed

Not standardized response on error #4

ramoncardena opened this issue Dec 1, 2018 · 4 comments

Comments

@ramoncardena
Copy link

ramoncardena commented Dec 1, 2018

When fetching data from the backend you got a response object. When there are errors the object is called 'errors' and if the errors are from validation, you get an array with the location, param, value and msg.

The problem is with POST /register, when you send an incorrect email like "asdasd@asdas" you don't get the validation error object, just a plain error object:

Object
errors: msg: "User validation failed: email: EMAIL_IS_NOT_VALID"
proto: Objec
t__proto__: Object

Instead of:

Object
errors:
msg: Array(1)
0: {location: "body", param: "email", value: "asdasd@asdas", msg: "EMAIL_IS_NOT_VALID"}
length: 1
proto: Array(0)
proto: Object
proto: Object

On the other hand, if you send an invalid email in POST /login you get the right validation error.

It's possible to standardize all errors to just get WHATEVER_WHATEVER (like IS_EMPTY)?

davellanedam added a commit that referenced this issue Dec 1, 2018
@davellanedam
Copy link
Owner

davellanedam commented Dec 1, 2018

Hi Ramon! Thanks, I just fixed it in release v.1.2.5. Again if you find anything else or have any ideas to improve, just let me know. Cheers!

@ramoncardena
Copy link
Author

ramoncardena commented Dec 1, 2018

Thanks Daniel! Works great with my frontend now!
I've done a couple of small changes to fit my needs, like I change some of the error returns from sentences to codes like EMAIL_IS_NOT_VALID so I can add the codes to my i18n file and write the error messages in multiple languages, and I have also added the role to the return when fetching profile, so I can check role at the moment without storing it in local storage or cookies. I can open open the issues for them if you want to add them.

@davellanedam
Copy link
Owner

Hi Ramon, well using uppercase and dashes for responses allows you to set a constant and then your message for i18n, I think it´s more readable that way so people understands easier, if changing to numbers works for you it´s great! But for learning purposes I think it´s better as it is now. Also the role is returning now when getting/patching profile in v.1.2.6.

@ramoncardena
Copy link
Author

Hi Daniel! sorry I haven't explained myself well! I meant that I changed some responses to uppercase and dashes to unify all the responses as uppercase and dashes. When I arrive to the office later I'll send you the responses I changed.

itundret added a commit to itundret/node-express-mongodb-jwt-rest-api-skeleton that referenced this issue Sep 6, 2021
rodrigoEhrmantraut added a commit to rodrigoEhrmantraut/Node-express-mongodb-skeleton that referenced this issue Sep 27, 2021
takond added a commit to takond/node-express-api-template that referenced this issue Oct 8, 2021
loveagile added a commit to loveagile/node-express-restapi that referenced this issue Nov 30, 2022
sailing-dev added a commit to sailing-dev/node-express-mongodb-jwt-rest-api-skeleton that referenced this issue Feb 3, 2023
sailingdev added a commit to sailingdev/node-express-mongodb-jwt-rest-api-skeleton that referenced this issue Apr 14, 2023
SuperFullstackDeveloper pushed a commit to SuperFullstackDeveloper/rest_api_jwt_mern- that referenced this issue Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants