4 ms·

The example about Amazon is inaccurate. Here is an Amazon URL: http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox-360/dp/B009PJ9L3Y/ref=sr_1_2?ie=UT

The example about Amazon is inaccurate. Here is an Amazon URL: http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox-360/dp/B009PJ9L3Y/ref=sr_1_2?ie=UTF8&qid=1365171686&sr=8-2&keywords=bioshock+infinite 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-360/dp/B009PJ9L3Y/ 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/ 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.

danso 14y ago
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
- potatolicious 14y ago
  > "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.
  - steveklabnik 14y ago
    > 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_style.htm#sec_5_2_1_1 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.
  - mddw 14y ago
    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.
  - danso 14y ago
    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.
randomdrake 14y ago
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=929505204/sr=2-1/002-9367729-7762218 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
- ben0x539 14y ago
  I suppose maintaining really old URLs is more of a priority when you can measure that they directly translate into sales. :)
susi22 14y ago
You can even do: http://amzn.com/B009PJ9L3Y http://amzn.com/B009PJ9L3Y
- walshemj 14y ago
  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.
  - mcovey 14y ago
    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.
    - zaphar 14y ago
      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.
  - goblin89 14y ago
    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.
  - aphexairlines 14y ago
    Mason emits a lot of unnecessary whitespace, but gzip helps a lot.
weinzierl 14y ago
SEO friendly: yes, human friendly: no Sure, the URL http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox-360/dp/B009PJ9L3Y/ 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/ http://www.amazon.com/flux-compensator/dp/B009PJ9L3Y/ or http://www.amazon.com/hackers-and-painters/dp/B009PJ9L3Y/ 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.
- FiloSottile 14y ago
  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.

danso 14y ago

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

potatolicious 14y ago
> "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.
- steveklabnik 14y ago
  > 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_style.htm#sec_5_2_1_1 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.
- mddw 14y ago
  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.
- danso 14y ago
  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.

randomdrake 14y ago

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=929505204/sr=2-1/002-9367729-7762218 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

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

susi22 14y ago

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

walshemj 14y ago
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.
- mcovey 14y ago
  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.
  - zaphar 14y ago
    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.
- goblin89 14y ago
  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.
- aphexairlines 14y ago
  Mason emits a lot of unnecessary whitespace, but gzip helps a lot.

weinzierl 14y ago

SEO friendly: yes, human friendly: no Sure, the URL http://www.amazon.com/Bioshock-Infinite-Premium-Edition-Xbox-360/dp/B009PJ9L3Y/ 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/ http://www.amazon.com/flux-compensator/dp/B009PJ9L3Y/ or http://www.amazon.com/hackers-and-painters/dp/B009PJ9L3Y/ 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.

FiloSottile 14y ago
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.