Yesterday, I was watching some season 6 episodes of Futurama (btw, this is their best season ever!) and I noticed the URLs in the website I was in (let’s call it foo.com). They were like:
http://foo.com/futurama/season/6/episode/9
I thought to myself “hey, this looks very clean and readable”. And then I noticed that it only has 1 less character than its non-rewritten counterpart:
http://foo.com/?futurama&season=6&episode=9
However, I’m pretty sure you agree that the second one is much harder to read. I asked for opinions on twitter, and got many interesting replies. Apart from the ones that completely missed the point, these were the core explanations:
- = and especially & are more complex and look more like letters, so our brain has trouble tuning them out (@feather @robert_tilt @rexxars @mrtazz @manchurian)
- Slashes have more whitespace around them, so they are less obtrusive (@feather @stevelove @kenny1987 @janl)
- They’re all visual noise, but we always have slashes in a URL, so using the slash to separate keys and values as well only introduces 1 separator instead of 3 (@bugster @craigpatik @nyaray)
- Slashes imply hierarchy, which our brains process easier than key-value pairs. Key-value pairs could be in any order, paths have a specified order. (@sggottlieb @edwelker @stevenhay @jwasjsberg @stazybohorn)
- Ampersands and equal signs are harder to type than slashes. They’re both in the top row and ampersands even need the Shift key as well. (@feather)
- Ampersands and equal signs have semantic meaning in our minds, whereas slashes not as much (@snadon)
Regarding hierarchy and RESTful design, the first example isn’t exactly correct. If it was hierarchical, it should be foo.com/futurama/seasons/6/episodes/9. As it currently stands, it’s key-value pairs, masquerading as hierarchical. However, it still reads better.
So I’m leaning towards the first three explanations, although I think all of them have a grain of truth. Which makes me wonder: Did we choose the wrong characters for our protocol? Could we have saved ourselves the hassle and performance overhead of URL rewriting if we were a bit more careful in choosing the separators back then?
Also, some food for thought: Where do you think the following URLs stand in the legibility scale?
http://foo.com/futurama/season=6/episode=9
http://foo.com/futurama/season:6/episode:9
http : //foo.com/futurama-season-6-episode-9 Â (suggested by Ben Alman)
Do you think there are there any explanations that I missed?