Hacker News new | past | comments | ask | show | jobs | submit login

> I always thought, if there’s a code that officially signals what we’re trying to signal, we should use it, and rely on it as “the signal”.

This is a line I hear a lot in regards to this general situation, and the interesting part is that the 400 code really does not signal the thing the developer is trying to signal, not at all. But a lot of devs have a weird hang-up about this for some reason, and will go to any lengths to not send a 200 response. I blame the REST cultists.




Well, 4XX are for client errors, so if the client fails authing to the API, it would be appropriate there. If the API fails authenticating to an API further down the chain, that shouldn't be returned as a 4XX status code, because it could be confused with the immediate API's auth.

HTTP status codes can be used to good effect if done thoughtfully, because there's often already a lot of logic in the useragent to handle some cases (such as redirects, etc). Not using anything except for 200 is limiting. Using a bunch of status codes to refer to things that make no sense is confusing. Defining a sane standard for how your application will choose between them that allows for the benefits they offer without confusing clients as to what is actually being communicated is the best of both though.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: