Comment by potatolicious | Hacker News Reader

Comment by potatolicious | Hacker News Reader

The example about Amazon is inaccurate.

Here is an Amazon URL:

http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...

Is it completely clean? Nope. It contains a lot of information that feed into the backend, but the core URL is this:

http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...

This URL will take you to the correct page, every time, and it doesn't take a genius to figure this out. It also doesn't take a genius to figure out what this page is about before you even paste the link into your browser. By putting the human-relevant portion of the URL as far forward as possible it's able to accomplish both priorities: giving the machine as much information as possible, and giving the human as much information as possible.

The trick here is that "Bioshock-Infinite-Premium-Edition-Xbox-360" is entirely superfluous. It is entirely there for SEO and human readability purposes. This URL works just fine and leads to the same place:

http://www.amazon.com/dp/B009PJ9L3Y/

Amazon isn't blind to these issues. So sure, you can take this very last URL and try to make a point about obfuscated URLs, but that's not what's actually in use at Amazon. It seems odd to pick them as an example when they're not even a violator.

[edit] It looks like HN truncates long URLs for display, which only goes further to prove the point.

Although slightly unrelated, I'd just like to add something else to commend Amazon when it comes to link handling. I'm extremely impressed at Amazon's ability to handle very old links to products. Here's a link to Hitchhiker's Guide to the Galaxy that I used on a webpage I built 13 years ago and it still works: http://www.amazon.com/exec/obidos/ASIN/0517149257/o/qid=9295...

Note: it is a particularly ugly link

  http://www.amazon.com/exec/obidos/ASIN/0517149257/o/qid=929505204/sr=2-1/002-9367729-7762218

I suppose maintaining really old URLs is more of a priority when you can measure that they directly translate into sales. :)

SEO friendly: yes, human friendly: no

Sure, the URL

http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox...

leads to the Bioshock article, but so does

http://www.amazon.com/flux-compensator/dp/B009PJ9L3Y/

or

http://www.amazon.com/hackers-and-painters/dp/B009PJ9L3Y/

In my opinion the only reason for the slug is SEO, everything else is a side effect which I personally find borderline dangerous.

BTW stackoverflow.com URLs work the same way.

Ok, it's not tamper-proof, but if I'm pretty sure that my friend that mailed me a amazon.com link is not attempting a cheap phishing attack, I can recognize the product directly from the email body. I would call this human friendly, IMHO.

You can even do: http://amzn.com/B009PJ9L3Y

you do realise that they are using rel=canonical here?

But OMG is amazons html fracking messy or what huge amounts of white space which increases the page size.

they own so much bandwidth it's probably cheaper for them to just send uncompressed html than to waste time + power recompressing it when things change. Being so large, they're an exception to the general rule.

The more pages you send to a user the costly a single byte on a page is. Conversly the more costly a single byte is the more money you can save by compressing or removing said byte. Owning lots of bandwidth is often highly correlated with sending lots of pages. I think you may find that it's more cost efficient for them to "waste" time and power recompressing than you think.

Scale challenges a lot of your preconceptions when you actually get there.

Probably leftovers from their templating engine?

I wonder if this really matters with gzip. Or at least whether traffic overhead beats one from implementing and using HTML compression.

I bet they have it measured.

Mason emits a lot of unnecessary whitespace, but gzip helps a lot.

The Amazon case is an interesting one because, despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs.

However, this raises up an important consequence of clean URL design: when you're offering things that may be classified in several categories, it requires good design on the backed/framework to make sure your URL taxonomy isn't overly constricting. For example, example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?

Either one is legit but creating and keeping consistent taxonomy is difficult enough on its own without worrying simultaneously what the URL looks like

> "example.com/toys/Nintendo-wii or example.com/consoles/Nintendo-wii?"

Why not both? The URL is just a URL - it does not need to reflect your underlying data model. There would probably be a canonical URL for use when the category context isn't available (say, "consoles"), but why not have multiple URLs lead to the same information?

> "despite the appeal of the OP's argument, one can hardly deny the success of Amazon's product listings in spite of their ugly URLs"

But they're really not ugly. In fact, given the complexity of the system they represent, they are remarkably human-friendly.

In an ideal world all ideas, all businesses, and all use cases can be fulfilled by simple URLs like "example.com/shockingly-unique-identifier", but we don't live in that world. Amazon has constructed human and machine-relevant URLs. The author's argument can be applied to many sites, but I don't think Amazon is one of them.

> it does not need to reflect your underlying data model.

Absolutely! In the REST parlance, resources (which are what URIs point at) do not map 1-1 with entities (which is your internal representation of business objects). If they do, you're quite possibly exposing too many internal details and making your application brittle.

> More precisely, a resource R is a temporally varying membership function MR(t), which for time t maps to a set of entities, or values, which are equivalent.

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch...

This is actually one of the more readable parts of Fielding's dissertation, read the whole section. The examples are great.

You can't have multiple URL leading to the same information because of SEO. Well, you can (with canonical meta and stuff), but it's not an ideal practice. It is often better to cater to robots rather than to humans. A sad truth, highlighting Google's failures.

I don't disagree at all, I'm just pointing out it requires an extra layer of logistics and maintenance that may outweigh the benefits of the beautiful URL. And in the rise of URL shorteners and the proliferation of UrL sharin/discovery via social media, I'd argue that the beauty-effect of URLs is even further diminished.

Just a couple months ago, I pushed out a major update to classiccars.com (it's still pretty messy) that cleaned up/reduced the url structure.. the old system had like 50 routing rules to support a wide variety of "friendly" urls for searches, and listing display... I reduced that to /listings/find/YEAR(s)/MAKE/MODEL?opts where all search params other than year/make/model were not part of the route, but querystring params... it didn't make sense to support all those routes (not to mention the old results paged via postback). (hint, you can set the page size up to 100 via a ps=100 querystring param, there's a few others not in the UI yet)... the UI is very similar to how it already was.

The new routes make more sense, and are imho more friendly. The same for listings/view/###/STUB though I put the number/id before the stub, it looks a lot better than it did. Also, I put permanent redirects for any old references to the canonical url. It took a bit of work, now some more updates are going in to make the title/description/h1's more friendly. It's more maintainable now, and some very old URLs are still supported.

Currently working on some other modernization bits, which means a lot of the cruft can finally get cleaned out (if a section at a time, slowly).. having a friendly/consistent url stucture is important imho.

This is why I fundamentally disagree with the 'friendly' URLs approach. URLs are meant to be unique and permanent resources. Injecting your information architecture or page title etc into this is a horribly leaky abstraction - and those things are meant to be able to change. Mixing them up either adds brittleness to them or means that your URLs are going to require constant grooming to keep in sync.

Reply on news.ycombinator.com