Nobody Understands REST or HTTP
blog.steveklabnik.com
Nobody Understands REST or HTTP
1–10 of 141 posts
Re: Nobody Understands REST or HTTP
#2Is there any way to make the browser do an Accept: application/csv header on a hyperlink?
I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv)
While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.
Re: Nobody Understands REST or HTTP
#3The problem with posts like these is that they say things like "THIS IS BAD!!!!!1" without saying why.
Re: Nobody Understands REST or HTTP
#4The problem with posts like these is that they say things like "THIS IS BAD!!!!!1" without saying why.
That's not true with this post in particular.
It's not saying various practices are "bad," but that they don't conform to REST or the principles laid out in the HTTP specs.
Re: Nobody Understands REST or HTTP
#5The problem with posts like these is that they say things like "THIS IS BAD!!!!!1" without saying why.
That's not true with this post in particular. It's not saying various practices are "bad," but that they don't conform to REST or the principles laid out in the HTTP specs.
The above quote "THIS IS BAD!!!!!1" was lifted directly from the article.
Re: Nobody Understands REST or HTTP
#6Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.
good point, as long as the browsers don't have convenient way of displaying you the possible displayable mime-types this function isn't very useful to the enduser.
Re: Nobody Understands REST or HTTP
#7Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.
They're ivory tower ideals.
The web has grown organically and it has the warts to prove it. It's useful to think about the spec and to work toward improvements, but if it's real world possible to have your services work well for mobile clients on m.domain.com and real world impractical to do so on your main domain (or any of the other examples regarding actions, languages, versioning, whatever)—then by all means, break the rules.
Re: Nobody Understands REST or HTTP
#8I've personally given up trying to save the term REST. It was hijacked and will never recover completely at this point. What I've been looking for is a good alternative name. Sometimes I'll write out representational state transfer which is clever enough to get past most REST pretenders but I have yet to find something short.
Re: Nobody Understands REST or HTTP
#9Earlier quoted context omitted.
That's not true with this post in particular. It's not saying various practices are "bad," but that they don't conform to REST or the principles laid out in the HTTP specs.
The above quote "THIS IS BAD!!!!!1" was lifted directly from the article.
Before he even discusses his individual points the author gives his definition of "bad," and the reason the other approaches are "bad." From the introduction:
> Let's talk about a few cases where either REST or HTTP (which is clearly RESTful in its design) solves a common web development problem.
> so they make up a partial solution that solves their given case but doesn't jive well with the way that everything else works
Re: Nobody Understands REST or HTTP
#10Is there any way to make the browser do an Accept: application/csv header on a hyperlink? I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv) While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.
If you do use content type negotation, you are best off giving each type a different url (with the conneg doing a redirect) if the representations are usefully different ie you might want to bookmark one or the other.
In practise no one does use it, so just forget about it.