Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Examples of Great URL Design (2023)

blog.jim-nielsen.com

Post reply on HN
Print view View original

81–90 of 163 posts

Re: Examples of Great URL Design (2023)

#81

Post by marcinreal »

robin_reala wrote: post #72

Back when I was working on GOV.UK Verify we had URLs that looked something like /verify-passport for English and /cy/verify-passport for Welsh. I made the decision that if readable URLs was a design goal they should be readable in both languages, and ended up localising them all to (for example) /verify-passport and /gwirio-pasbort. No idea if anyone ever noticed, but sometimes it’s nice to sweat the small stuff.

I had the same thought for a restaurant website that served multiple languages. I figured customers might glance at the URL when it's being shared, and appreciate it being in their language.

What do you do when the translated slug happens to be the same in multiple languages? I ended up still having the country code in the slug.

Re: Examples of Great URL Design (2023)

#82

Post by johannes1234321 »

twic wrote: post #62
ttepasse wrote: post #43

We take the typical blog url design (/2024/08/14/slug) for granted but back in the very early 2000s pretty much every blog tool had its own URL design. Matthew Thomas back then took an inventory: https://web.archive.org/web/20030810201315/http://mpt.phrase... He was on the search for his ultimate blogging system, where this "cruft-free" URL structure should be used: https://web.archive.org/web/20051107103030/http://m…

He calls file extensions cruft, but i've come to value them. They are a simple way to indicate file type - desired or offered - which is easily understood by machines and people. I currently work with an API which does a bit of content negotiation using the Accept header, so clients can request data in various formats - application/json for a snapshot, text/event-stream for an updating feed, or text/html for an inter…

> He calls file extensions cruft

I think that refers mostly to the .php and .asp of the time. Those don't tell a thing to the user.

Re: Examples of Great URL Design (2023)

#83

Post by robin_reala »

marcinreal wrote: post #81
robin_reala wrote: post #72

Back when I was working on GOV.UK Verify we had URLs that looked something like /verify-passport for English and /cy/verify-passport for Welsh. I made the decision that if readable URLs was a design goal they should be readable in both languages, and ended up localising them all to (for example) /verify-passport and /gwirio-pasbort. No idea if anyone ever noticed, but sometimes it’s nice to sweat the small stuff.

I had the same thought for a restaurant website that served multiple languages. I figured customers might glance at the URL when it's being shared, and appreciate it being in their language. What do you do when the translated slug happens to be the same in multiple languages? I ended up still having the country code in the slug.

Luckily we only had <10 user-visible pages in our part of the service, so I didn’t have to worry about that.

Re: Examples of Great URL Design (2023)

#84

Post by cynicalpeace »

I've come to regret that most of my projects have this URL design- mainly because it gets harder to track via third party analytics platforms like Sentry and Clarity.

eg. series/9876545678 and series/098767890 get treated differently and the analytics get difficult to merge. But really they're the same page just hydrated with different data.

Should've used query params, eg series?id=9876545678

Re: Examples of Great URL Design (2023)

#85

Post by amadeuspagel »

I think the URL design of stackoverflow leavs room for improvement. The id should not be necessary. StackOverflow demands unique questions. If a question doesn't have a unique slug, is the question unique? Great URL design to me is if the slug is suffficient for uniqueness, without an id.

Re: Examples of Great URL Design (2023)

#86

Post by robertclaus »

From a URL=Resource perspective I don't love unstructured strings in the url because they make it trickier (never impossible) to extend with sub-resources. For example, if I have a url for a blog post with a slug, it's more difficult to represent a comment as a sub-record of that post:

`my.domain/post/123/my-great-slug-that-is-pretty-long-but-doesnt-matter/comment/456`

vs

`my.domain/post/123/comment/456`

Re: Examples of Great URL Design (2023)

#87

Post by arccy »

amadeuspagel wrote: post #85

I think the URL design of stackoverflow leavs room for improvement. The id should not be necessary. StackOverflow demands unique questions. If a question doesn't have a unique slug, is the question unique? Great URL design to me is if the slug is suffficient for uniqueness, without an id.

you should be able to refine question titles

Re: Examples of Great URL Design (2023)

#88

Post by amadeuspagel »

ttepasse wrote: post #43

We take the typical blog url design (/2024/08/14/slug) for granted but back in the very early 2000s pretty much every blog tool had its own URL design. Matthew Thomas back then took an inventory: https://web.archive.org/web/20030810201315/http://mpt.phrase... He was on the search for his ultimate blogging system, where this "cruft-free" URL structure should be used: https://web.archive.org/web/20051107103030/http://m…

I guess this reflects a view of blogging that maybe is more what people today would use twitter or mastodon for, with lots of blogposts with the same title like "open thread" or "links for sunday". Today people mostly use blogs to publish essays, and then a slug based on the title should be sufficient, since you're not going to publish two essays with the same title. That's what substack uses.

Re: Examples of Great URL Design (2023)

#90

Post by anamexis »

mrweasel wrote: post #78

The Slack URL scheme, and a few others mentioned in other comments take me right back to hp.com/go/ , so hp.com/go/proliant would take you to Proliant servers, maybe. The idea was really cool, but from talking to people at HP at the time, the implementation was apparently a complete nightmare done with an insane number of rewrites. It was sort of a hit and miss if the thing you typed in after /go/ would actually take…

How was the implementation hard? It seems like it would be a bog-standard set of redirect rules.
Post reply on HN