We have broken HTTP

Re:We have broken HTTP by stevenspins on Monday January 12, 2015 @05:19AM (#8873126)

HTTP comprehension and usage are critical. People wonder why websites don't perform and api are difficult to program for. I have seen that developers have this weird need to create your own method and means of communicating errors. Even ws-* developers don't use soap errors. That is what we are talking about mostly in this article non-standard messages/state.

Treating your application and data as resources (REST is the style of the web) and leveraging the power of HTTP so powerful. You are not a crabby old man. If you do count me in, 33 years old. I could make a career consulting and only fixing http and resource abstraction/usage problems.

IMO though educating our fellow developers on HTTP is easy compared to the REST HATEOAS constraint.

[ Parent | on HN ]

Re:We have broken HTTP by bluetomcat on Monday January 12, 2015 @07:16AM (#8873472)

> I have seen that developers have this weird need to create your own method and means of communicating errors.

Developers ignore most of the status codes because they introduce unnecessary complexity on both ends (client and server) and do not always map well with the application logic. With JSON payloads, HTTP is used as a "light vehicle" to carry the application logic. Since the payload is going to be specially interpreted anyway, I don't see a benefit in cramming legacy HTTP cruft in the headers and in status codes.

The really annoying thing is the web server spitting out HTML on error conditions instead of the expected JSON.

[ Parent | on HN ]