Live data from Hacker News

Choosing between names and identifiers in URLs

cloudplatform.googleblog.com

51–60 of 157 posts

Re: Choosing between names and identifiers in URLs

#51

"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.

3xx redirection requires the backing-store to maintain some kind of permanent edit history, and is therefore not necessarily something one can assume one will have.

There's also the problem of aliasing; if another book by the same name is later added to the shelf, the hierarchical name now references an entirely different resource.

Re: Choosing between names and identifiers in URLs

#52
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...

eh. You can do that with query strings and hashes in URLS anyway. https://news.ycombinator.com/user?id=digikata&profile=bad-pe...

Re: Choosing between names and identifiers in URLs

#53

Earlier quoted context omitted.

I don't buy it. Redirecting to canonical URLs is canonicalization 101. https://support.google.com/webmasters/answer/139066?hl=en#4 Also, what would be an example of same-origin redirect abuse?

Bypassing black lists when posting links while still benefiting from crawlers following the links comes to mind. During the 2000s, following links for a forum or blog was way too expensive, so they had black lists of dirty words to avoid porn sites spaming and get juice during the page rank golden years where any back reference mattered. Hence it was just easier, to avoid the filters, to create non blacklisted domain…

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.

Re: Choosing between names and identifiers in URLs

#54
Identifying changing "stuff" in the real world is for me a fundamental topic of any serious data modeling for any kind of software (be it an API, a traditional database stuff, etc). Identity is also at the center of the entity concept of Domain-Driven Design (see the seminal book of Eric Evans on that: https://www.amazon.com/Domain-Driven-Design-Tackling-Complex...).

I started changing my way of looking at identity by reading the rationale of clojure (https://clojure.org/about/state#_working_models_and_identity) -> "Identities are mental tools we use to superimpose continuity on a world which is constantly, functionally, creating new values of itself."

The timeless book "Data and reality" is also priceless: https://www.amazon.com/Data-Reality-Perspective-Perceiving-I....

More specifically concerning the article, I do agree with the point of view of the author distinguishing access by identifier and hierarchical compound name better represented as a search. On the id stuff, I find the amazon approach of using URN (in summary: a namespaced identifier) very appealing: http://philcalcado.com/2017/03/22/pattern_using_seudo-uris_w.... And of course, performance matters concerning IDs and UUID: https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-ca....

Happy data modeling :)

EDIT: - add an excerpt from the clojure rationale

Re: Choosing between names and identifiers in URLs

#55

Earlier quoted context omitted.

Bypassing black lists when posting links while still benefiting from crawlers following the links comes to mind. During the 2000s, following links for a forum or blog was way too expensive, so they had black lists of dirty words to avoid porn sites spaming and get juice during the page rank golden years where any back reference mattered. Hence it was just easier, to avoid the filters, to create non blacklisted domain…

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 to test that assumption with my clients money :)

Re: Choosing between names and identifiers in URLs

#56
post #4

Good advice. Interesting that Canonical URLs aren't mentioned. But the sheer arrogance of serving a webpage that doesn't render any text unless you execute their JavaScript really annoys me. It's not a fancy interactive web-app, it's a webpage with some text on it.

The notion of surfing the web without JavaScript enabled is increasingly antiquated. You can't even log into Google without JS enabled; it's necessary to mandate it because of iframe attacks.

Re: Choosing between names and identifiers in URLs

#57
post #24
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...

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

Re: Choosing between names and identifiers in URLs

#58
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…

The annoying part is doing the database lookups to check for collisions / canonicalization, so what would your lib be generalizing?

Yeah good point. Maybe it'd be better as a blog post with an associated repo in one implementation (Node + Mongo) and great documentation.

Re: Choosing between names and identifiers in URLs

#59
post #4

Good advice. Interesting that Canonical URLs aren't mentioned. But the sheer arrogance of serving a webpage that doesn't render any text unless you execute their JavaScript really annoys me. It's not a fancy interactive web-app, it's a webpage with some text on it.

The notion of surfing the web without JavaScript enabled is increasingly antiquated. You can't even log into Google without JS enabled; it's necessary to mandate it because of iframe attacks.

Not all web pages are (or at least need to be) web apps. Logging into an account vs reading a static page is apples to oranges.

Mandating JS to get any content, no matter how static, seems like the start of the death of e.g. Linked Data and a the web as an open standards based platform. I know I'm in the minority but diversity is a strength, and there are few places more important than the web.

Re: Choosing between names and identifiers in URLs

#60
post #16
post #13

Isn't one problem with this is that intermediate caches now have two resources that represent the same thing, therefore invalidation of intermediate caches will be nearly impossible?

Cache invalidation remains one of the two hard problems in computer science (the other being naming things and off by one errors).

Off by one errors basically don't exist if you use modern languages and practices.
Post reply on HN