I don't think that I can fully agree with the idea that a news article written in English is not different content from the German version.
Nobody Understands REST or HTTP
21–30 of 141 posts
Re: Nobody Understands REST or HTTP
#22I don't think that I can fully agree with the idea that a news article written in English is not different content from the German version.
Maybe not a news article. But for example, if you're seeing a user's profile with the UI in English, is it really a different resource that the same user's profile in German? I don't think it is.
Re: Nobody Understands REST or HTTP
#23I don't think that I can fully agree with the idea that a news article written in English is not different content from the German version.
Technology-puristic take on this is that both the English and the German versions are just representations of the 'real' story underneath.
Generally works better for more real entities like for example specific products, than for articles.
Re: Nobody Understands REST or HTTP
#24Is 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.
Accept header is all but useless these days. Servers rarely look at the Accept header that is sent with the request, and browsers can rarely know ahead of time what type of content to expect when merely clicking on a URL. Check out this blog post by Eric Law on IE and the Accept Header (http://blogs.msdn.com/b/ieinternals/archive/2009/07/01/ie-an...)
Re: Nobody Understands REST or HTTP
#25Is 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.
Accept header is all but useless these days. Servers rarely look at the Accept header that is sent with the request, and browsers can rarely know ahead of time what type of content to expect when merely clicking on a URL. Check out this blog post by Eric Law on IE and the Accept Header ( http://blogs.msdn.com/b/ieinternals/archive/2009/07/01/ie-an... )
It depends on whether you're doing a normal website or if it's (also?) a webservice. There are more HTTP clients besides browsers.
Re: Nobody Understands REST or HTTP
#26While I generally agree with the principles underlined in the article, using the Accept-Language header is definitely not the right way to control internationalization.
Remember that one of the advantages of URLs is the ability to easily share them, however I'm not sure I'd be comfortable sharing content that could show up translated to some recipients, based on the language of their browser/application/computer. For example, most CMS systems assume that the content can be completely different between languages (for the same article): you can have the full text in English and only a teaser in other languages.
Maybe not a pure REST approach but using '/en','/pt','/fr' in the URL has proven to be much easier and safer, from my experience.
Re: Nobody Understands REST or HTTP
#27The part about using "Accept" headers instead of "/v1/" links really threw me for a loop. The APIs I've come across from major applications (e.g. Twitter, Foursquare, Instagram) all have versioning in the link structure, not in the "Accept" headers. I understand that this post is supposed to highlight what REST APIs should do, not what everyone should do, but the author's emphatic insistence that "THIS IS BAD!!!!!1" leaves me confused as to what the proper method is.
Re: Nobody Understands REST or HTTP
#28Is 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, bre…
I think his main problem with the m.domain.com was redirecting to the main page. If it did a 303 See Other to the mobile version of the same article it wouldn't break the spec, as far as I can understand it.
Re: Nobody Understands REST or HTTP
#29While I generally agree with the principles underlined in the article, using the Accept-Language header is definitely not the right way to control internationalization. Remember that one of the advantages of URLs is the ability to easily share them, however I'm not sure I'd be comfortable sharing content that could show up translated to some recipients, based on the language of their browser/application/computer. For…
It depends on what content is translated. I think that Accept-Language is OK for UI elements - seeing 'entrar' instead of 'log in' and elements like that. For actual content, probably not.
Re: Nobody Understands REST or HTTP
#30I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this: /networks/ /networks/girl_talk/ /networks/girl_talk/tracks/ /search?term=bass&sort=artist He argued for URLs like this (note the pluralization): /networks/ /network/girl_talk/ /network/girl_talk/tracks/ /search/bass/sort/artist/ My case boiled down to, “A URL represents th…
/search/bass/sort/artist/
This URL looks more like a different view on /search/bass resource, so /search/bass?sort=artist is IMHO more appropriate.