`_path` Routes Considered Harmful
·There’s been some talks lately on relative versus absolute routes and where they should be used.
Personally, I consider the point moot. If you have such a powerful tool at your disposal (Rails) there is one thing you certainly should do, once and for all - make all URLs both absolute and canonical. Here is the reasoning for that:
- Canonical URLs work in standalone documents (like PDF and downloaded pages). Anywhere you transition from displayable HTML to something else, you have to go canonical
- Atom and RSS feeds are busted when you use relative URLs. Granted, there is the xml:base but some feed readers just don’t give a shit (making all your links dead). Nothing is more frustrating than having unclickable links. NetNewsWire, last time I checked, did not honor
xml:base
. This situation obliges you to rewrite all URLs that go out to feeds - The same for sent email - there is no mechanism for specifying a URL base for hyperlinks in mail messages.
Also, if you promote web service consumption off your app (REST or otherwise) you oblige the consumer to do path-munging for every redirect, every cross-reference and every parse just to drill down your site structure (all these ugly url.path = something
things come from that).
So if you ask me, I’d just hardwire *_path
to raise or play through to *_url
. These are processor cycles (and wire bytes) well spent, because they simplify the consumption of your website outside of anything except the browser, and free you from deciding every time which one you need. Additionally, modern times never cease to amaze us with regards to ways our content can bleed out of the browser.
At some point I had to write a plugin to enforce canoncal/absolute URLs in text segments, and for Inkpot (the engine running this site) I use canonical URLs for the absolute most of the links and cross-references. The exception is the stuff going through the Camping router, but my gut feeling tells me that the use of Camping will be abolished here anyway.
Just my 2 cents.