* Joel Bernstein <[email protected]> [2009-11-15 16:30]: > No no no! Allow the client and server to negotiate what content > to serve for the resource identified. As a URI to a resource > which may vary according to many dimensions, > /path/to/some/content is fine. > > GET /path/to/content HTTP/1.1 > Accept-Language: en > Accept: text/html
Conneg sucks. It’s a good idea for non-human-readable content served in a variety of formats, but for variants of anything that’s like a “page” you should have separate URIs, so that people can reliably bookmark one of them, or send someone else a link to talk about it and not have the other person see a completely different page (or file or whatever), etc. It’s OK to accept conneg on neutral URIs and then *redirect* to specific URIs based on the Accept-* headers. But don’t make conneg the *only* way to pick a specific version of a resource. > They are different *representations* of the same *resource*. They are almost never *exact* equivalents. There are almost always slight differences in content depending on language. _The medium is the message._ And there is no reason not to have more than one URI for the same resource anyway. Yes, you should pick one of them as canonical, and unless you have good reason for doing otherwise, all the non- canonical URIs be redirects. But these are merely good ideas, not hard and fast rules. > If you really must stick it in the URL, I'd go for something like: > /path/to/content/en > /path/to/content/pt_BR > etc Worst of all worlds, IMO. The query parameter is easiest to implement for the server, while the path prefix allows the user to hack the URI conveniently (so the latter is what I would do). Your suggestion is harder to implement than both and makes URIs annoying to hack. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
