I always use and recommend these to give extra context to client errors: 409 Conflict - used when trying to create en entity that already exists, such as a user account with a unique email constraint. 422 Unprocessable Entity - when the JSON body payload fails to validate 415 Unsupported Media Type - when requesting with a content-type or mime type the endpoint does not accept, such as posting XML or uploading an EXE instead of a JPG 410 Gone - similar to a 404, but this implies that the resource existed at some point, but no longer does - such as a banned user account 412 Precondition Failed - when attempting to associate a dependency with a given resource that doesn't exist or cannot be associated with the resource I see lots of people, instructors on RUclips especially, using 400 for all or most of the above. While a client error is a client error and requires handling regardless, the proper status code adds semantics and context to the error.
Great dude, I was just searching documentation about this, and after a while of reading I could not get this understandable examples for real life issues.
405 Method Not Allowed is also quite common, it means that you used a method verb ("GET", "PUT", "POST") that this route does not support. It is also very easy to fix usually, and I am always happy that this has an entirely separate status code because I know exactly what went wrong.
Thank you for all the hard work you've put into this. I truly appreciate the informative content and the approachable manner in which you presented it. On a related note, I'm curious - what tool or software do you use to create the animated infographics?
I'm wondering how others decide to walk the line between 1) giving enough information that legitimate users of your API can find useful, and 2) giving too much information to bad actors that can use that information to compromise your site. I tend to skew more towards the latter, and return information that is deliberately vague; I don't want provide specifics on why an API call failed.
The "P" in HTTP stands for *Protocol.* The protocol level is *NOT* the application level. Many REST concepts are fantastic, but trying to shove application level errors into protocol level error handling has caused endless pain for both backend and frontend developers. Stack Overflow has questions about HTTP errors with dozens of highly upvoted answers that are mutually exclusive. Even if you think your techniques for handling HTTP errors are superior, it's certain that at least 35% of other developers disagree with you. *The way you handle HTTP errors is wrong, and that's a guarantee.*
Hey you missed 418 "I'm a teapot"!
I always use and recommend these to give extra context to client errors:
409 Conflict - used when trying to create en entity that already exists, such as a user account with a unique email constraint.
422 Unprocessable Entity - when the JSON body payload fails to validate
415 Unsupported Media Type - when requesting with a content-type or mime type the endpoint does not accept, such as posting XML or uploading an EXE instead of a JPG
410 Gone - similar to a 404, but this implies that the resource existed at some point, but no longer does - such as a banned user account
412 Precondition Failed - when attempting to associate a dependency with a given resource that doesn't exist or cannot be associated with the resource
I see lots of people, instructors on RUclips especially, using 400 for all or most of the above. While a client error is a client error and requires handling regardless, the proper status code adds semantics and context to the error.
Great dude, I was just searching documentation about this, and after a while of reading I could not get this understandable examples for real life issues.
405 Method Not Allowed is also quite common, it means that you used a method verb ("GET", "PUT", "POST") that this route does not support. It is also very easy to fix usually, and I am always happy that this has an entirely separate status code because I know exactly what went wrong.
Thanks. I'm now on the backend part of my fullstack journey, so these are very timely. Gonna go through the previous uploads soon
curl -v for verbose reponses including headers was always my favourite way to do this kind of debugging.
Great Video. I am a beginner and that is really helpful to me.
Very great choice of words, thank you sir
Thanks for this brief on the common HTTP status codes, and thanks for teaching us!🤓
Thank you for all the hard work you've put into this.
I truly appreciate the informative content and the approachable manner in which you presented it.
On a related note, I'm curious - what tool or software do you use to create the animated infographics?
>what tool or software do you use to create the animated infographics?
It says exactly in the 2nd sentence of the video's description.
You should do a video in E-Tag header and associated mechanism.. I wish I had known that a bit early in my career
Very nice and useful information, thank you :)
So much I love this video is directly this what I need and must know!
Very nice reading voice brother.
"500...that's the server's cry for help." xD Thanks for the great lesson.
Next video suggestion: HTTP header directives
Nice informative. Thank you
I give this 200 :p
This is so useful. Thanks!
I'm wondering how others decide to walk the line between 1) giving enough information that legitimate users of your API can find useful, and 2) giving too much information to bad actors that can use that information to compromise your site. I tend to skew more towards the latter, and return information that is deliberately vague; I don't want provide specifics on why an API call failed.
Good job!
Great Video , Thanks
super❤
Thank you sir..
Please make a video on http headers. Thank you!
418 I'm a teapot
420 Enhance your calm
Learnt a lot, thank you
What do I should use when I want to update my side in the backend and the website will be online again in 1-2 hours? 200 or 503?
I tried to delete an entry in the database, I got 200 Ok on my postman. Do I have to explicity mention in RepsonseEntity that i want 204 status code?
As a programmer, i can confirm 500 is the most painful. You never know whats going on
Recap:
100 - informational
101 - switching protocols
200 - success
201 - created
204 - empty
300 - reroute
301 - forwarding address
302 - temporary route
304 - not modified
400 - client error
401 - unauthorized
403 - forbidden
404 - not found
427 - too many requests
500 - server error
502 - bad gateway
503 - service unavailable
The "P" in HTTP stands for *Protocol.* The protocol level is *NOT* the application level. Many REST concepts are fantastic, but trying to shove application level errors into protocol level error handling has caused endless pain for both backend and frontend developers. Stack Overflow has questions about HTTP errors with dozens of highly upvoted answers that are mutually exclusive.
Even if you think your techniques for handling HTTP errors are superior, it's certain that at least 35% of other developers disagree with you. *The way you handle HTTP errors is wrong, and that's a guarantee.*
あなたは日本人ですか。maybe the accent gives it away!
英語を勉強したい？
You are very good, but let me know! I can help with intonation and small mistakes! :)
❤️#गुजराती गाना बेवफा 2023 नई टीमली# दिल ठीक💔 करने
Why is 401 unauthorized and not unauthenticated ?
I'm a teapot
now postman and insomania both required to open an account.
Shameful. I feel sorry for Insomnia's creator who sold it believing it would be in good hands.
Hi sahn
RRR