Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing between names and identifiers in URLs

cloudplatform.googleblog.com

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Choosing between names and identifiers in URLs

#101

Post by ballenf »

saurik wrote: post #19
yathern wrote: post #3

Great post - I quite like the stackoverflow.com style of `stackoverflow.com/questions/ / `, where can be changed to anything, and the link still works. This allows for easy URL readability, while also having a unique ID. In the context of this post (the library example) that would look like library.com/books/1as03jf08e/Moby-Dick/

Doing this means that: 1) there are now an infinite number of URLs for every one of your pages that may end up separately stored on various services (mitigated for only some kinds of service if you redirect to correct), 2) if the title changes the URLs distributed are now permanently wrong as they stored part of the content (and if you redirect to correct, can lead to temporary loops due to caches), 3) the URL is now…

> 3) the URL is now extremely long and since most users don't know if a given website does this weird "part of the URL is meaningless" thing there are tons of ways of manually sharing the URL that are now extremely laborious,

I'm missing something -- what does length have to do with the difficulty of sharing a URL? I can't remember the last time I typed out any URL past the TLD.

Re: Choosing between names and identifiers in URLs

#102

Post by Bromskloss »

sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

> So Google's going to kill the URL, Facebook's going to kill the username, and someone (apparently not Microsoft) is going to kill the filename.

Not if we kill them first!

Re: Choosing between names and identifiers in URLs

#104

Post by adrianratnapala »

lucian1900 wrote: post #89
sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

Apple are the ones to kill the file name, with iOS.

Yes. And yet they are still with us, and are still with ordinary users too.

Re: Choosing between names and identifiers in URLs

#105

Post by int_19h »

nayuki wrote: post #34

The article talks about referring to resources by using URLs containing opaque ID numbers versus URLs containing human-readable hierarchical paths and names. They give examples like bank accounts and library books. This problem about naming URLs is also present in file system design. File names can be short, meaningful, context-sensitive, and human-friendly; or they can be long, unique, and permanent. For example, a…

One thing I'd love to see, in conjunction with this, is some kind of MVCC with snapshot transactions on filesystem level. So you don't really mutate files - you create new versions of them, and then old versions get GC'd eventually if nothing references them (which may not be the case if you e.g. have a backup).

Problem is, our existing file I/O APIs are very much centered around the notion of mutable files, and globally shared state with no change isolation.

Re: Choosing between names and identifiers in URLs

#107

Post by ademarre »

always_good wrote: post #92
chrismorgan wrote: post #86

Earlier quoted context omitted.

301 may be dangerous, because browsers cache them. Suppose the client follows a link to old-slug after the slug has been changed to new-slug. The server responds 301 → new-slug. The client caches that redirect , so that if you request old-slug it will immediately take you to new-slug without querying the server. Then the object’s slug is changed back to old-slug (perhaps the change was made in error). Now a request t…

I just tried it locally in Chrome/Firefox/Safari. Ends up working, no issue.

This used to be a serious problem. It may be fixed now, but Firefox would eternally cache 301s unless explicitly told not to. This is why I configure all of my servers to disallow caching of 301s.

Re: Choosing between names and identifiers in URLs

#108

Post by jaza »

HumanDrivenDev wrote: post #106

A bit of an aside: why is it not standard practice to format uuids in a radix 64 encoding? It cuts down the identifier size from 32 to 22 characters

I'm a fan of formatting UUIDs in Base62 (which is like Base64 but doesn't require any non standard alpha-numeric characters). I have used Base62-encoded UUIDs in URLs and APIs on several occasions. It's not standard, but if you google around you'll see that it's gaining popularity, because of the shorter identifier length.

Re: Choosing between names and identifiers in URLs

#109

Post by avg_dev »

sgentle wrote: post #85

The root of the issue here is that URLs are trying to be human-meaningful and machine-meaningful at the same time, but those requirements are fundamentally incompatible. Humans work well with ambiguity and context. You know that when your coworker says "Bob's birthday is this weekend" you know she means her husband Bob, not Bob from accounting who nobody likes. And you even prefer that system to having an unambiguous…

this was really beautifully written.

Re: Choosing between names and identifiers in URLs

#110

Post by ademarre »

saurik wrote: post #19
yathern wrote: post #3

Great post - I quite like the stackoverflow.com style of `stackoverflow.com/questions/ / `, where can be changed to anything, and the link still works. This allows for easy URL readability, while also having a unique ID. In the context of this post (the library example) that would look like library.com/books/1as03jf08e/Moby-Dick/

Doing this means that: 1) there are now an infinite number of URLs for every one of your pages that may end up separately stored on various services (mitigated for only some kinds of service if you redirect to correct), 2) if the title changes the URLs distributed are now permanently wrong as they stored part of the content (and if you redirect to correct, can lead to temporary loops due to caches), 3) the URL is now…

> 1) there are now an infinite number of URLs for every one of your pages that may end up separately stored on various services

Sometimes I call this a URL black hole.

In all fairness, black holes are everywhere when you consider that most web servers ignore unrecognized query params for routing. Examine this URL:

https://news.ycombinator.com/item?t=choosing-between-names-a...

Of course the difference is that Hacker News doesn't disseminate URLs of that form, but that doesn't mean someone couldn't pollute the internet with them.

Post reply on HN