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

91–100 of 157 posts

Re: Choosing between names and identifiers in URLs

#91

Post by derefr »

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…

> "Bob-4592-daring-weasel-horseradish"

You could easily have a bijective encoding at a frontend proxy that translates between the above and e.g.

> "4592-13f7-de41-203a"

(i.e. discards the descriptive part of the slug, and then reverses the unique words back into their index-positions in the same static 64k-word dictionary used for generation, resulting in a regular UUID.)

Re: Choosing between names and identifiers in URLs

#92

Post by always_good »

chrismorgan wrote: post #86
simcop2387 wrote: post #22

Earlier quoted context omitted.

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 h…

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.

Re: Choosing between names and identifiers in URLs

#93

Post by DougWebb »

CharlesW wrote: post #88
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…

> 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. The TLDR of TFA is that an API can support both human-meaningful and machine-meaningful URLs.

Not really. TFA doesn't talk about what happens when the search fails. sgentle is talking about using human-meaningful urls as identifiers, which doesn't work when the search fails.

Re: Choosing between names and identifiers in URLs

#94

Post by s17n »

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.

Re: Choosing between names and identifiers in URLs

#96

Post by toast0 »

sametmax wrote: post #55
always_good wrote: post #53

Earlier quoted context omitted.

I have a hard time believing that modern search engines are so incapable that they have to devalue redirects to the point that honest users have to worry about it.

Well that's just what I know about the things we did then. I'm not working in porn anymore, so I'm missing the new cool tricks, or abuses, depending of your point of view. But the community is VERY creative. Now the last time I did change massively URLs for a client website and noticed a significant drop in traffic that took a few months to recover was years ago. So the situation might have changed. But I'm not going…

It's been a long time since I accidentally got to porn on the internet. I think that kind of thing is mostly dead (although some of the 'related articles' sections look pretty iffy), and instead porn monetization has moved towards people intentionally looking for porn.

Re: Choosing between names and identifiers in URLs

#98

Post by simcop2387 »

Tushon wrote: post #81
simcop2387 wrote: post #22

Earlier quoted context omitted.

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 h…

Minor correction, because dealing with this is a part of my job: Almost no browsers have implemented changing bookmarks in response to 301 redirects. Link has further context and some testing. https://superuser.com/questions/151366/do-browsers-change-ur...

Interesting, I had always gone with that since the RFC says it should happen. Good to know.

Re: Choosing between names and identifiers in URLs

#99

Post by Nicksil »

jonknee wrote: post #90
afandian wrote: post #46

Earlier quoted context omitted.

Your argument holds for web apps where it might be extra work to do progressive enhancement. But this is literally a webpage of text. It is more work to get JS involved. Humans using off the shelf browsers aren't the only ones who consume webpages.

> But this is literally a webpage of text. It is more work to get JS involved. Humans using off the shelf browsers aren't the only ones who consume webpages. Sort of, the contents of the post are in a database somewhere. It's not like someone uploaded a .html page to Blogspot and they converted it into JS. The JS makes it easier for users to customize templates. The main reason you'd want to avoid doing something lik…

> Sort of, the contents of the post are in a database somewhere. It's not like someone uploaded a .html page to Blogspot and they converted it into JS. The JS makes it easier for users to customize templates.

That's not always the case, either, however. There are a great many (majority?) of database-driven websites out there with framework-rendered templates; Django, Flask, Ruby on Rails, etc. They are not constructed using -- nor are they dependent upon -- JavaScript.

Re: Choosing between names and identifiers in URLs

#100

Post by ballenf »

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 halfway. ("If you want to talk to a computer, you have to think like one.")

I'd say it's programmers or deadlines that mean that the extra work of accounting for ambiguous data gets skipped. It doesn't take a neural net to look at the recently called list for the most frequent or even most recently dialed [wife's first name].

One irony of your "Bob" example is that sometimes using someone's last name actually adds ambiguity: "It's Bob Lingendorfer's birthday this weekend!" ... "Who is Bob Lingendorfer? ... Ohhh, you mean your husband!".

Maybe it's not irony, it's just that people read a lot into data and might assume that all of it is relevant to the task at hand. My car kind of does the opposite and lazily stops at the first three "close enough" hits on my wife's name.

Post reply on HN