Live data from Hacker News

Examples of Great URL Design (2023)

blog.jim-nielsen.com

91–100 of 163 posts

Re: Examples of Great URL Design (2023)

#91
post #30

I might be an outlier, but I don't like slugs in URLs. They make URLs unnecessarily long, often forcing people to use URL shorteners -- completely defeating the purpose. They get awkward when the author changes the title. Other commenters mentioned some tricks to get around this issue, but all involve redirects. Cools URLs shouldn't change in the first place. They don't copy cleanly if you use nonalphanumeric charact…

> They don't copy cleanly if you use nonalphanumeric characters, as in nearly every language other than English.

I haven't noticed this ever being an issue.

At least in Firefox, non-ASCII characters will show as-is in the URL bar, but in the copied URL they will be properly encoded.

Re: Examples of Great URL Design (2023)

#93

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.

I think the date is still extremely valuable. Knowing whether something is from last month or a decade ago makes a huge difference. It's also useful so that URL's can be sorted by date.

Also, "you're not going to publish two essays with the same title" feels false. If you write 1,000 pieces and use short titles and tend to write about the same subjects, it feels extremely likely that you'll wind up repeating titles.

Re: Examples of Great URL Design (2023)

#94

I like that GitHub supports file-like suffixes to get different views of the same content. https://github.com/torvalds/linux/commit/{hash} https://github.com/torvalds/linux/commit/{hash}.patch https://github.com/torvalds/linux/commit/{hash}.diff

I agree that is a cool feature. I would say it's from its Rails background where such a thing is encouraged (.json or .html (or no extension)) on a resource give you two different outputs

Re: Examples of Great URL Design (2023)

#95
post #62

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…

That's fine (and already common) for images, JSON, etc.

But nobody wants webpage URL's that randomly end in .php, .htm, .html, .aspx, and so forth. That's just noise that is both gibberish and entirely irrelevant to the user.

Re: Examples of Great URL Design (2023)

#96

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.

> then a slug based on the title should be sufficient, since you're not going to publish two essays with the same title.

Disambiguation is one thing, but as a reader, I really like having the date indicated in the URL for informational purporses. It's very helpful.

Re: Examples of Great URL Design (2023)

#97
post #37

Earlier quoted context omitted.

This can be a complex topic if you don’t set clear constraints on what constitutes a valid character in your URL or domain. For instance, in query parameters, spaces are encoded as '+'. But what if '+' is also a valid character in your domain? You then need to disambiguate i.e between "name?foo+bar" meaning "foo bar" or "foo+bar". Which one is the user actually referring to? In our case, we ended up needing users to…

Wouldn't you just encode the "+" if you wanted it as a literal?

A better example is the name: "foo%20bar".

A user might have entities named "foo bar", "foo%20bar", and "foo%2520bar". Sometimes, mistakes happened because users forgot to double encode or they used the wrong protocol. As this names were used in URL, query parameters, and the body, and each has its own.

As I mentioned, with clear constraints and rules, we can accomplish anything we need, it can get complex. My takeaway from this project is to limit the valid characters and make it simple for everyone.

Re: Examples of Great URL Design (2023)

#99
post #2

An example of a not-so-great URL design: Amazon product links have an optional slug before everything else like `{slug}/dp/{id}`. So you end up copying a gigantic URL everytime you wish to share a product unless you use the share product button to get the shortened link.

It is a curious decision why they chose to put the ID before the slug.

Stack Overflow, in contrast, puts the ID first, followed by an often very long slug. Which seems to be the more common pattern generally, as far as I can tell.

I do wonder what their rationale was/is.

Post reply on HN