On Wed, Nov 18, 2009 at 9:55 AM, Aristotle Pagaltzis <pagalt...@gmx.de>wrote:
> * Joel Bernstein <j...@fysh.org> [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. > I think this is very good advice. > > > 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. > I think Catalyst makes the path prefix the easiest. WIth the query parameter (which I'm doing now to be compliant with a legacy app) it's trivial to by using "around uri_for", but I'd much rather do something once (modify $->req->base) than override every uri_for. I do have a slight fear of the query parameter messing with caching. I doubt it's much of an issue these days, though. -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
