Notes on status codes for my students

gistfile1.md

Core status codes -- can look at as a checklist when building API

• 2XX - success case

  • 200 - Success - good for GET, often the default https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/200

  • 201 - Created - good for POST https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/201

  • 204 - No content - successful, BUT server does not send you information besides an "OK, your request succeeded, 204." Sometimes used on create, never used to get data, but more often for liveness endpoints (endpoints checked every 1 second - 10 minutes that just serve to respond "OK 204 I am alive" for monitoring) like www.something.com/health-check, which is used by monitoring or even sites like IsItDown.com - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/204

• 4XX - any missing or inacessable resource case "Oops you screwed up."

  • 400 - Invalid Request - textbook "you screwed up". Example route /users/123 exists and accepts params. Howevewr the param must be a number and someoneo does /users/mary, this would cause a 400 because we do not want to query our database with bad data https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400

  • 401 - Unauthorized - example is viewing a page you have to be logged in to see - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

  • 403 - Forbidden - example is viewing someone's profile when you are ARE logged in BUT not allowed because you are blocked, not in their organization, etc - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403

  • 404 - Page not Found - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/404

  • 422 - Unprocessable Entity - tried to handle the request and it ended up being unprocessable - Another classic "oops you screwed up" - example is bad characters in the request like "https://( ͡° ͜ʖ ͡°).something.com/" - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422 "profile.something.com" might be valid, so it tries to process, but the kaomoji is bad and causes the error -

• 5XX - Server error "Oops we screwed up."

  • 500 - Internal Server Error -often the default when your code blows up for unknown reasons - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/500

  • 502 - Bad Gateway - less frequent but you want to know so you do not panick when it happens - Core error in node app.js, server cannot start up [AKA server died due to OOM, nginx/proxy/gateway died, something else] -- first step of mediation is to see if server is running and if not try a restart redeploy BUT solutions will vary https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/502

  • 503 - Service Unavailable - less frequent but you want to know so you do not panick when it happens - same notes as above minus the nginx / proxy note - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/503

  • 504 - less frequent but similar to 503, usually different because the response doesn't come back at all, usually the client even terminates the connection first - https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/504

REDIRECTS -- not common in restful design, more for navigation and page serving contexts but will come up

• 3XX - any redirect case
  • 302 - TEMPORARY redirect, good to start with because permanent redirects (301) cache and cause bugs

More notes on DEVOPS!

502 vs 503, liveness probe

client
 \/			IF the client cannot even reach the proxy and
 			cannot even get a response from it, 502

proxy - load balancer - apache/nginx/f5/ELB common implementations
 \/			Usually happens after a long timeout.
 			IF something blows up between proxy and server,
 			AKA proxy ok but server bad, OR proxy can respond
 			in a basic way, but is broken in how it tries to
 			reach the server, THEN throw a 503
server


Another concept here -- "server timeouts vs client timeouts"
	- never have a timeout more than 30 seconds

more notes on a liveness probe

 SUCCESS_CODE = 204 // OR SUCCESS_CODE = 200 is also very common // Main reason for 204 in this example -- WE NEVER USE response.data, we don't NEED data! ​ setInterval(() => { fetch("https://something.com/liveness") .then( if (response.ok && response.status === SUCCESS_CODE) { . . . if successful, literally do nothing. Interval will rerun and re-check . . .) } else { throw Error('Bad status code or response'); }}) .error((e) => callAndEmailAndWakeUpAllEngineers(e)) }, 1000);