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

121–130 of 157 posts

Re: Choosing between names and identifiers in URLs

#121

Post by shaan7 »

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…

"Humans work well with ambiguity and context"

Not so sure about the "well" part there. I've encountered people who love to make guesses about the context (and others who actually wish you'd do the same). That coupled with ambiguity creates disasters varying from ordering the wrong lunch to broken relationships.

I'd rather have humans take less pride in being ambiguous and make attempts to be as precise as possible.

Re: Choosing between names and identifiers in URLs

#122

Post by a13n »

kalleboo wrote: post #120
a13n wrote: post #57

Earlier quoted context omitted.

It's way more than that. – Automatically handling duplicates – Avoiding needing to include the unique ID in the URL – Updating the URL after editing the post – Redirecting previous versions to the new version

Wordpress has supported all of that for as long as I can remember

What's your point?

Re: Choosing between names and identifiers in URLs

#123

Post by kijin »

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…

Usernames and filenames are not just compromises, nor arbitrary sequences of characters.

Usernames reflect a fundamental human desire to create an alter ego free from the burden of their legal name and the socioeconomic context they're in. If Samual Clemens were a blogger, he would write under the username @marktwain. Alonso Quixano might call himself @donquixote69. Anakin Skywalker will want to be known (and feared) as @darth_vader, not because his real name is unusable, but because he prefers to be called Darth Vader.

People have had titles and pseudonyms for ages. Usernames are a continuation of this tradition, not merely an invention of the 20th century. The global uniqueness requirement is of course rather silly, but enforcing a real-name policy on everyone is just as silly. If our grandchildren have no concept of usernames/handles/whatever, it might be more a sign of great oppression and loss of privacy than of technological progress.

Ditto for filenames. We programmers have a habit of using weird filenames that really do look like arbitrary sequences of characters, but most of the rest of the world just uses human-readable filenames like "Financial report 3Q 2017". Change a few numbers inside, and it's still "Financial report 3Q 2017", content-addressing be damned. The document might not be stored as a physical file in the future, but then again, have files ever been physical? Filenames are just labels that we stick on a logical chunk of information. Implementation details can differ, but the concept itself is not going anywhere as long as humans like to put stable labels on mutable things. (This, unfortunately, tends to escape notice when your concept art for a filename-less system only contains a handful of photographs with pretty thumbnails.)

Re: Choosing between names and identifiers in URLs

#124

Post by buro9 »

The author took an easy way out by recommending a canonical identifier based URL and a named URL, and then choosing a library as an example.

Books in a library are seldom renamed, if ever. The named URL would be almost as permanent as the canonical URL.

However in their earlier example of a bank account, a personal account name is typically the account holder name and the type of account, and both of these could be subject to change as a result of marriage, death, or the change in products offered by a bank. Even then, the rate of change is low.

A better example that the author could have (should have?) used is that of a news website where the article title may change frequently and yet there is a desire to make the link indicate the type of content at the destination... this is the real crux of the issue.

On a news site a canonical identifier driven URL may be correct... but does not sell or communicate the story behind the link and the link is likely to be shared without context. Sure you may see `example.com/news/a49a9762-3790-4b4f-adbf-4577a35b1df7` but this could be any news... it is far less obvious what is behind the link than the banking example as diversity in news stories is huge.

Yet the named URL would likely fail too, as once created and shared it should not mutate or at least should remain working... and yet the story title is likely to be sub-edited multiple times as news evolves.

The best scheme was not even mentioned in the article... combining both an identifier with a vanity named part: `example.org/news/a49a9762-3790-4b4f-adbf-4577a35b1df7_choosing_between_names_identifiers_URLs` . The named part can vary as it is not actually used for lookup, only the prefix identifier is used for lookup.

Though that has it's own downside... one can conjure up misleading named sections for valid identifiers to misdirect and mislead.

Re: Choosing between names and identifiers in URLs

#125

Post by spotman »

ballenf wrote: post #100
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…

> Machines, on the other hand, hate ambiguity and context. When I ask my car to call my wife using only her first name, it suggests a list of 3 people who I'm not even sure how they got in my contacts list. Siri, on the other hand, gets it right every time with the exact same request. I wouldn't say my car hates ambiguity, the programmers failed to bridge the gap to human/machine interaction and meet the person halfw…

that’s funny. i have the exact inverse problem. when i ask siri to call my wife ( by her first name only ) it gives me a list of two to pick from, whereas my car does the opposite and calls my wife.

darn computers!

Re: Choosing between names and identifiers in URLs

#126

Post by lloeki »

lwansbrough wrote: post #10

Nice, this reflects the choice I've made with a recent API design. This is especially important for entity names you don't control. For example, we ingest gamertags and IDs from players of Xbox Live, PSN, Steam, Origin, Battle.net, etc. - each have their own requirements in terms of what is allowed in a username, and even whether or not they're unique. Often you can't ensure a user is unique by their gamertag alone.…

> Reality is that search is almost always required in these cases, and that's why we've implemented search in the way described in this article, with each result pointing to a GUID representing a gamer persona

This also solves the technical† challenge of handling renaming, even within a single platform. (Steam, I hate you.)

† Another challenge is social, esp. regarding abuse.

Re: Choosing between names and identifiers in URLs

#127

Post by amelius »

s17n wrote: post #94
amelius wrote: post #7

Why not make every URL that's shown in the title bar a permalink by default? That way, you have the best of both worlds in all cases. If another object tries to use the same URL as another object (which was used first), then a new URL must be generated (just add something at the end of the name).

Because then you are compromising the utility of your url-as-search semantics, complicating your implementation, and probably distorting your data and/or schema. A better solution is to make the distinction between "display" and "permanent" url a first class concept.

> Because then you are compromising the utility of your url-as-search semantics

Could you explain why?

Re: Choosing between names and identifiers in URLs

#128

Post by wodenokoto »

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…

It's kinda funny you mention that Google will kill the url.

For at least the past decade, advertisement in Japan has been showing people which search term to enter to find the website instead of a url.

Re: Choosing between names and identifiers in URLs

#129

Post by MaxBarraclough »

wodenokoto wrote: post #128
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…

It's kinda funny you mention that Google will kill the url. For at least the past decade, advertisement in Japan has been showing people which search term to enter to find the website instead of a url.

I can't tell if that's a worse idea than QR codes of URLs.

Re: Choosing between names and identifiers in URLs

#130

Post by hyperpape »

yathern wrote: post #40
hyperpape wrote: post #33

Earlier quoted context omitted.

I don't have a direct piece of evidence, but most users don't even know about ctrl-f, so I think they don't copy and paste. They click (or tap, these days) on links. https://www.theatlantic.com/technology/archive/2011/08/crazy... Most users click links.

I meant in the context of sharing links, either on a board like this or in a text. But that does bring a up a good point of how many users know how to copy/paste? Among all internet users, I would conservatively assume 30%+ do. Among people who have posted a link to social media or forums, I would assume %80+. But I'd be interested to see how off I am.

There's a reason there are those share buttons on every website that's chasing viral traffic.

I suspect most people who share on Facebook share via those, or via the Facebook app's own internal web viewer. I would assume Twitter is a bit more savvy, but I still would not bet strongly that a majority of people on Twitter know about copy-paste.

Post reply on HN