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

151–157 of 157 posts

Re: Choosing between names and identifiers in URLs

#151

Post by sametmax »

toast0 wrote: post #96
sametmax wrote: post #55

Earlier quoted context omitted.

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.

It's more thanks to ad blockers than anything though.

Re: Choosing between names and identifiers in URLs

#152

Post by bo1024 »

naasking wrote: post #150
bo1024 wrote: post #87

Something was bugging me about this, but I had to think hard to figure it out. The article is largely based on a misguided premise: the idea that URLs should be conceptualized as either names or identifiers. URLs are neither: they are addresses of web pages. The things located at the URL may have names or identifiers, but by design of the web the stuff located at an address is mutable while the address is immutable.…

> The things located at the URL may have names or identifiers, but by design of the web the stuff located at an address is mutable while the address is immutable. But an address is a designator/identifier.

I'm not sure about that. An address makes no promises (technically speaking) about what you will find at that address.

You can give an object some metadata like "current address", but that's different from saying the address alone identifies the object.

Re: Choosing between names and identifiers in URLs

#153

Post by naasking »

bo1024 wrote: post #152
naasking wrote: post #150

Earlier quoted context omitted.

> The things located at the URL may have names or identifiers, but by design of the web the stuff located at an address is mutable while the address is immutable. But an address is a designator/identifier.

I'm not sure about that. An address makes no promises (technically speaking) about what you will find at that address. You can give an object some metadata like "current address", but that's different from saying the address alone identifies the object.

> I'm not sure about that. An address makes no promises (technically speaking) about what you will find at that address.

I don't see how that's relevant. An address, in principle, merely designates a particular location, perhaps physical like a street address, or logical like a memory address. In the context of a search or lookup, you can obtain what's contained at that address.

Similarly, a URL designates a particular resource location, as exemplified by its full name, Uniform Resource Locator. In the context of a client/server request, you can similarly obtain a representation of what's at a URL.

Re: Choosing between names and identifiers in URLs

#154

Post by sametmax »

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…

Except all the actors you mentions create centralized closed system for profit to replace standard vastly compatible simple primitives.

So i'm not sure it's a win

Re: Choosing between names and identifiers in URLs

#155

Post by matt_kantor »

couchand wrote: post #133
kijin wrote: post #123

Earlier quoted context omitted.

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

> 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 is the point that I think is completely lost on the author of the article, probably because of a focus on API design. It's a good thing that we can replace that dog-eared copy of Moby Dick with a…

All good points, however one thing missing is that humans also want to be able to refer specifically to "that dog-eared copy of Moby Dick". Facts like "that dog-eared copy of Moby Dick is missing page 34" or "that dog-eared copy of Moby Dick is actually a super valuable early edition" should not change their referent when the library gets a shiny new copy of the book.

And that's exactly how I read the article: both mutable and immutable references are nice to have for different use cases.

Re: Choosing between names and identifiers in URLs

#156

Post by couchand »

matt_kantor wrote: post #155
couchand wrote: post #133

Earlier quoted context omitted.

> 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 is the point that I think is completely lost on the author of the article, probably because of a focus on API design. It's a good thing that we can replace that dog-eared copy of Moby Dick with a…

All good points, however one thing missing is that humans also want to be able to refer specifically to "that dog-eared copy of Moby Dick". Facts like "that dog-eared copy of Moby Dick is missing page 34" or "that dog-eared copy of Moby Dick is actually a super valuable early edition" should not change their referent when the library gets a shiny new copy of the book. And that's exactly how I read the article: both m…

Yes, that's true abstractly. However, A, those sorts of references are much less common in web pages than in physical descriptions (at least in my estimation) (though they're very common in APIs), and B, those repointable references are not the same as a search - I want to uniquely refer to the current value of this pointer, while allowing the publisher to relink as appropriate.

The article reads as universal URL design advice, but I'd argue the points only really apply to APIs.

Re: Choosing between names and identifiers in URLs

#157

Post by MaxBarraclough »

tyingq wrote: post #131
MaxBarraclough wrote: post #129

Earlier quoted context omitted.

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

Remember the cuecat? https://en.m.wikipedia.org/wiki/CueCat

Hadn't heard of that. Looks singularly awful.

Like URLs, but proprietary, exclusionary, and riddled with privacy and security issues.

Post reply on HN