👎🏻 This person does not appear to understand HTTP.
What he says about 428 doesn’t make sense. That status means “you sent a GET request without a condition like If-None-Match or If-Modified-Since, but this resource requires that you use one.” (He seems to have admitted he doesn’t know what a conditional request is.)
409 does not apply to condition failures; that’s 412.
Also, 300 isn’t for navigation, it’s for choosing representations (data types) of a single resource.
And of course 205 is the wrong response when a form submission fails, because 2xx codes indicate success, not failure.
I thought this was a mildly interesting article. There is some discourse on the idea of HTTP status codes being a bit dated for the modern web, and that anything beyond the idea of a 200 or 404 should just be communicated in the response body.
The simplicity and immediate understandability of many of these status codes certainly has its charm though.
Many of these codes are still extremely important, although often at lower levels than what a typical web-app developer sees. They are by no means merely “simple” or “charming”, they are the bedrock of the Web.
For example, conditional requests and codes like 412, 304 are crucial for caching by user agents and proxies, and for techniques like MVCC and optimistic concurrency.
201 vs 200 conveys information in the response to a PUT about whether the resource already existed, and 409 indicates a PUT conflicts with existing data. 405 indicates a method isn’t useable with a resource, and 400 means the request is syntactically invalid.These are important parts of REST.
206 is used for partial GETs and range requests, which allow browsers to do things like resuming an interrupted download.
301, 302, 307 all enable redirects to work.
The HTTP/1.1 RFC explains all these in detail; it’s not abstruse, although it’s very long and there is a ton of stuff to keep track of.
It’s cute, but as @snej points out it’s easy to get these wrong or just for people to have differing interpretations of what they mean for a particular API. I still think it’s better to use specific error codes in the body.
It’s not just about their interpretation. They can never map to the wide range of domain specific errors your application can return. And more importantly any proxy between client and server can return them.
So if your query returns a 404 status, you have no idea which software actually returned the error, which resource is “not found”, and what not found actually means precisely
HTTP is a transport protocol, and HTTP status codes should only be used to signal errors in the transport layer. Infortunately most HTTP APIs happily mix application and transports, but it does not make it right.
Hmm, I would suggest that HTTP is very much at the application layer, and not merely a transport layer protocol. This (transport protocol) view of HTTP, in my estimation, led to, or at least abetted many initiatives* that also deliberately ignore the status codes available, and how HTTP works, and as such, led to the loosening of general understanding (which in turn begets these “charming” views mentioned earlier in this interesting thread).
👎🏻 This person does not appear to understand HTTP.
What he says about 428 doesn’t make sense. That status means “you sent a GET request without a condition like If-None-Match or If-Modified-Since, but this resource requires that you use one.” (He seems to have admitted he doesn’t know what a conditional request is.)
409 does not apply to condition failures; that’s 412.
Also, 300 isn’t for navigation, it’s for choosing representations (data types) of a single resource.
And of course 205 is the wrong response when a form submission fails, because 2xx codes indicate success, not failure.
[Comment removed by author]
I thought this was a mildly interesting article. There is some discourse on the idea of HTTP status codes being a bit dated for the modern web, and that anything beyond the idea of a 200 or 404 should just be communicated in the response body.
The simplicity and immediate understandability of many of these status codes certainly has its charm though.
Many of these codes are still extremely important, although often at lower levels than what a typical web-app developer sees. They are by no means merely “simple” or “charming”, they are the bedrock of the Web.
For example, conditional requests and codes like 412, 304 are crucial for caching by user agents and proxies, and for techniques like MVCC and optimistic concurrency.
201 vs 200 conveys information in the response to a PUT about whether the resource already existed, and 409 indicates a PUT conflicts with existing data. 405 indicates a method isn’t useable with a resource, and 400 means the request is syntactically invalid.These are important parts of REST.
206 is used for partial GETs and range requests, which allow browsers to do things like resuming an interrupted download.
301, 302, 307 all enable redirects to work.
The HTTP/1.1 RFC explains all these in detail; it’s not abstruse, although it’s very long and there is a ton of stuff to keep track of.
It’s cute, but as @snej points out it’s easy to get these wrong or just for people to have differing interpretations of what they mean for a particular API. I still think it’s better to use specific error codes in the body.
It’s not just about their interpretation. They can never map to the wide range of domain specific errors your application can return. And more importantly any proxy between client and server can return them.
So if your query returns a 404 status, you have no idea which software actually returned the error, which resource is “not found”, and what not found actually means precisely
HTTP is a transport protocol, and HTTP status codes should only be used to signal errors in the transport layer. Infortunately most HTTP APIs happily mix application and transports, but it does not make it right.
Hmm, I would suggest that HTTP is very much at the application layer, and not merely a transport layer protocol. This (transport protocol) view of HTTP, in my estimation, led to, or at least abetted many initiatives* that also deliberately ignore the status codes available, and how HTTP works, and as such, led to the loosening of general understanding (which in turn begets these “charming” views mentioned earlier in this interesting thread).
*I’m thinking of early SOAP, WS-Deathstar, etc.