this post was submitted on 22 Mar 2025
755 points (98.8% liked)
Programmer Humor
22155 readers
3428 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
A 2xx means success to its requester. If you have an error in step 6 out of 13 that breaks the resource action, you shouldn't be returning a success.
You might argue what to return and what kind of information to include in the response (like tracking numbers), but it shouldn't be a 2xx and I don't see how a misleading 200 would be more helpful than a 400 bad request.
That's when you use a 5xx status, then. The client doesn't care how many other services you reach out to in order to fulfill their request. A 5xx code also covers failures in other parts of the system.
error codes aren’t about who’s at fault… you don’t send a 404 because it’s the users or the servers fault. it’s information… a 404 says something doesn’t exist… it’s nobody’s fault; it just is
a 4xx says the request, if tried again without changes or external intervention, is unlikely to succeed
a 5xx says the request might have been fine but some other problem that you can’t control occurred so may be retried without changes at a later time
these are all standard things that are treated in standard ways by generic HTTP libraries… look at, eg axios: a javascript HTTP library that’s often thinly wrapped to build API clients… a 200 is just passed through as success, where 4xx and 5xx will throw an error: exactly what you’d want if you try to retrieve a non-existent object or submit a malformed payload…
this is standard behaviour for a lot of HTTP libraries, and helps people accidentally write better code - an explosion is better than silence for unhandled exceptions
they are all the same thing; there is no useful, practical distinction between them
it’s an empty array: not found when requesting something specific is an error… that’s different to here is the complete set of 0 objects… like like if you have an array and request an index that doesn’t exist you get an exception, but that doesn’t mean an empty array is exceptional: it is in fact very valid
well, it is an error though. you have requested a URI for an object that doesn’t exist: it doesn’t matter whether it’s a resource or an individual thing
remember that HTTP youre asking the server for some object matching a URI: please give me the object matching /users/bananoidandroid and /userssssss/bananoidandroid may both not be found for the exact same reason: the object referenced by that string does not exist
here’s the spec definition for 404
when you’re dealing with specs, deciding not to follow them because you feel like they’re wrong is not appropriate… this leads to bugs and issues in compliant tools because they make assumptions about what things mean
200 means the thing that you asked completed successfully
here’s the definition of 200:
*edit: when talking about compliant, standard tools the classic example is transparent cache: a GET should not transform the resource and thus a GET with response of 200 can be cached… an API that uses a GET to modify a resource may cause transparent proxies (or CDNs) to significantly mishandle the user request… same goes for 200 vs 4xx and 5xx: proxies know that 200 means what it means and may cache based on that, where 5xx should never be cached and 4xx is probably dependant on which specific 4xx