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

21–30 of 157 posts

Re: Choosing between names and identifiers in URLs

#21

Post by digikata »

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/

This seems like it's vulnerable to some form of abuse.

library.com/books/1as03jf08e/Moby-Dick/

library.com/books/1as03jf08e/Hitchhikers-Guide-to-the-Galaxy

Now lead to the same place...

Re: Choosing between names and identifiers in URLs

#22

Post by simcop2387 »

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…

The usual way I've seen to deal with this kind of ambiguity is by doing a 301 redirect so that bookmarks get changed and the url in the address bar is also changed. It doesn't fix external parties linking to the site with the now deprecated url but there was never anything you could reasonably do about that.

> If you are going to insist upon doing this, how about doing it using a # on the page, so at least everyone had a chance to know that it is extra, random data that can be dropped from the URL without penalty and might not come from the website and so shouldn't be trusted?

The fragment doesn't get indexed by search engines so not many will see it. Along with that, in my understanding, having something human readable in the URL helps with SEO in at least google an bing so doing this could hurt your search rankings which isn't a good thing.

Re: Choosing between names and identifiers in URLs

#23

Post by hughes »

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) and 2) are not a problem if the server accepts any value for the title token (which is the case on stack exchange)

3) is not a problem for hyperlinks (url not visible) or for even direct links (not burdensome length), and if you care about a short url an even shorter form is available

4) seems like a feature? the person sending the link will only ever include as much information as they deem necessary anyway. If the recipient wants more info they'll either request it or click the link.

Trust is an interesting point, but if you can equally put literally anything in the client side anchor (eg. meta.stackexchange.com/questions/148454/#definitely-not-a-rick-roll) so I don't see what a viable alternative would be.

Re: Choosing between names and identifiers in URLs

#24

Post by jlg23 »

a13n wrote: post #6

For Canny, I wrote some awesome code that I'm proud of that turns a "post title" into a unique URL. https://react-native.canny.io/feature-requests/p/headless-js... For example, a post with title "post title" will get url "post-title". Then a second post with title "post title" will get url "post-title-1". Since there's only one URL part associated with each post, it's a unique identifier. This gets rid of the ugly id…

> For Canny, I wrote some awesome code that I'm proud of that turns a "post title" into a unique URL.

Did you mean "slug"? What you are describing is a basic feature of most blogging software since the inception of blogs...

Re: Choosing between names and identifiers in URLs

#25

Post by andrewstuart2 »

"The case for identifiers" is really more of a case for surrogate keys. Surrogate keys need not be opaque, but rather are distinguished by the fact that they're assigned by an authority and may be completely unrelated to the properties of an entity.

Natural keys, meaning entity identification by some unique combination of properties, are hard to get right (oops, your email address isn't unique, or it's a mailing list) and a pain to translate into a name (`where x = x' and y = y' and z = z'`, or `/x/x'/y/y'/z/z'`, etc.).

Surrogate keys, on the other hand, make it easy to identify one and only one object forever, but only so long as everybody uses the same key for the same thing.

And as mentioned in the article, the most appropriate is usually both. Often you don't have the surrogate key, so you need to look up by the natural key, but when you do have the surrogate key, it's fastest and most likely to be correct if you use that in your naming scheme.

Re: Choosing between names and identifiers in URLs

#27

Post by yathern »

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…

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

What services? Web crawlers? I'm sure the ones I would care about are smart enough to know how this works. There are many ways infinite valid URLs can be made. Query params, subdomains and hashroutes to name a few.

> 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),

You don't redirect. The server doesn't even look at the slug part of the URL for routing purposes. You can change the url with javascript post-load if it bothers you (as stackoverflow does). Cache loops are an entirely avoidable problem here.

> 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

Extremely long and extremely laborious seems a bit of an exaggeration. Most users copy and paste, no? Adding a few characters of a human readable tag doesn't warrant this response I feel. Especially when the benefit means that if I copy and paste a url into someplace, I can quickly error-check it to make sure it's the title I mean. When using the share button, the de-slugged URL can be given.

> users who share the links will think "the person can read the URL, so I won't include more context" and the person receiving the links thinks "and the URL has the title, which I can trust more than what some random user adds".

I guess? I wont bother with a rebuttal because this issue seems so minor. The benefit far outweighs some users maybe providing less context because the link url made them do it. If someone says "My typescript wont compile because of my constructor overloading or something please help", I can send stuff like:

stackoverflow.com/questions/35998629/typescript-constructor-overload-with-empty-constructor

stackoverflow.com/questions/26155054/how-can-i-do-constructor-overloading-in-a-derived-class-in-typescript

which I think is so much more useful than just IDs.

> Many web browsers don't even show the URL anymore: the pretense that the URL should somehow be readable is increasingly difficult to defend

Most do. Even still, the address bar is not the only place a URL is seen. Links in text all over the internet has URLs - particularly when shared in unformatted text (ie not anchor tags). And URLs should be readable to some extent. Would you suggest that all pages might as well be unique IDs? A URL like:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Is much better than

https://developer.mozilla.org?articleId=10957348203758

> how about doing it using a # on the page, so at least everyone had a chance to know that it is extra

Fair enough - I think that's a fine idea.

Re: Choosing between names and identifiers in URLs

#28

Post by spiralpolitik »

"The downside of the second example URL is that if a book or shelf changes its name, references to it based on hierarchical names like this one in the example URL will break."

The author appears to have forgotten about 3xx redirection codes which were intended to solve that very problem.

Re: Choosing between names and identifiers in URLs

#29

Post by TeMPOraL »

detaro wrote: post #17
Moter8 wrote: post #15

Earlier quoted context omitted.

Strangely enough, discourse uses the following style: https://meta.discourse.org/t/deleted-topics-where-are-they/2... /t/ for topic, slug for readability, then a topic id and at last a reply id.

and your comment is the perfect demonstration why: when truncated, the id gets cut off before the slug.

Which is... something you don't want to happen, right?

Re: Choosing between names and identifiers in URLs

#30

Post by ehsankia »

Moter8 wrote: post #15
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/

Strangely enough, discourse uses the following style: https://meta.discourse.org/t/deleted-topics-where-are-they/2... /t/ for topic, slug for readability, then a topic id and at last a reply id.

So does reddit. Go to any comment section. You can remove the latter part with the title and only leave the identifier, and the link will still work. The short link actually only contains the identifier.
Post reply on HN