4 ms·
A quick glance at history of HTTP can explain this without incompetence. HTTP is fundamental to the world wide web and existed from the beginning in 1989. Field
by dustingetz 9y ago
A quick glance at history of HTTP can explain this without incompetence. HTTP is fundamental to the world wide web and existed from the beginning in 1989. Fielding's dissertation introduced the idea of REST in 2000. And REST became part of mainstream client libraries in what, 2010? So there's a 20 year period during which code was written against HTTP libraries which were not idiomatic from a REST perspective. Returning status codes in the response body is a common workaround for compatibility with code written in this 20 year window.
- boubiyeah 9y agoNor was it even just idiomatic HTTP. Using the proper HTTP status or verbs for instance is not REST, just caring about the HTTP spec.
- dustingetz 9y agoyou're right, a little deeper digging and i learned that in 1989 http only had GET! I dont think verbs came until '96
- strictnein 9y agoI've seen plenty of this is in code written in the past 5 years, some within the last year or two.
- JimDabell 9y agoStatus codes aren't something introduced by REST, they've been a standard part of HTTP since HTTP 1.0. They've been in widespread use for decades. People use 200 for errors for a few reasons, but it's not because HTTP 0.9 didn't have them.
- mattmanser 9y agoI started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes. There's a load of early, popular, Stack Overflow questions that revolve around what status to return when, and how to actually return those codes in your language. For example, in ASP.Net/IIS it was actually quite hard to stop IIS 6 (?) from swallowing your 500 xml response and serving a custom html error page. If I remember correctly some browsers didn't support PUT properly either. So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use. I remember this article from the first time around, when people were really getting into REST and there was a fierce debate about strict REST Vs RESTful. In reality RESTful has mainly won and this article was on the wrong side of history.
- self-diversity 9y agoThe endpoints in question are not typically used by humans driving a browser, so these objections don't seem applicable.
- MichaelGG 9y agoI think IIS7's 5xx idiocy was more driven by misguided security concerns. Same as HTTP.sys requiring you to get permission to listen on a port versus not needing any permission if you just open a socket. Or same reason telnet.exe doesn't get installed by default.
- deleted 9y ago[deleted]
- JimDabell 9y ago> I started programming professionaly in 2005 and I can assure you that back then, outside of the browsers, people really didn't know or understand response codes. > So while you are technically correct, the codes were in use, you are historically wrong, few people outside of a small community understood their use. I started in the late 90s, and even back then they were commonly used. They weren't just well understood by developers, but they were actually in non-developer's lexicons as well. If you asked the typical geek back then what a 404 was, chances are they'd be able to tell you that it meant something was missing. So I don't agree with you that they were understood by "few people outside of a small community" at all. Using status codes has been standard practice for decades. Maybe it took a couple of years at the beginning of your career for you to notice them, but there simply wasn't this time period of decades when they weren't in use until REST came along.
- mattmanser 9y agoGiven that ajax was only added to browsers in 1999 and AJAX didn't really catch on seriously until 2003/2004ish, what you're claiming is at odds, again, with actual history. 404s are a different matter because you'd get 404 pages, so it's not at all an argument to support your position. It doesn't mean developers understood what to return from an ajax call, or that they understood HTTP verbs. I'll remind you again that it was actually fairly hard to return the correct codes from a lot of frameworks, so objective facts are at odds with your recollection of events. I stick by my assertion that the vast majority of web developers in our industry didn't really understand http until the latter half of the 2000s. I also specifically remember presentations to all our developers both junior and senior of how browser caching worked, which to most developers at the time was a bit of a mystery, and the correct headers to return to control it. Here are some examples from 2008 of developers on SO discussing things which seem obvious today: http://stackoverflow.com/questions/165779/are-the-put-delete-head-etc-methods-available-in-most-web-browsers http://stackoverflow.com/questions/165779/are-the-put-delete... http://stackoverflow.com/questions/165720/how-to-debug-restful-services http://stackoverflow.com/questions/165720/how-to-debug-restf...
- dustingetz 9y agoyeah but there are bits in the ~2000 era backend request pipeline that don't understand anything but 200 or do weird things, embedding response code in 200 body lets us tunnel through whatever weird legacy shit
- JimDabell 9y ago> there are bits in the ~2000 era backend request pipeline that don't understand anything but 200 There's badly written buggy software from any time period doing all sorts of crazy shit, but only accepting 200 certainly wasn't the norm, or even commonplace back then.
- liveoneggs 9y agoIt comes from SOAP, which is supposed to be "protocol independent" so you would return statuses inside of the envelope section of the XML.