On: Things you should do now (2011)

[Cthulhu_]

My main gripe with UUIDs at the moment is that they look ugly in urls :/

[ozim → Cthulhu_]

You should not use your database identifiers in urls anyway.

[krab → Cthulhu_]

You can encode it to a shorter string if you use larger alphabet. Still, it's 16 bytes of information, so not as short as sequential IDs.

See for example https://pypi.org/project/shortuuid/

    >>> shortuuid.uuid()
    'vytxeTZskVKR7C7WgdSP3d'

[ivanbakel → krab]

Those shorter strings can come with their own caveats. Long-form UUIDs have the nice property of being URL-safe - but IIRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs. For correct semantics, short UUIDs have to go in the request parameters instead.

[hansvm → ivanbakel]

Most of the url (including the path pieces) is supposed to be case sensitive unless otherwise specified for a given protocol (and treating e.g. %3A the same as %3a). This should be the most recent RFC on the topic: https://tools.ietf.org/html/rfc3986#section-6.2.2.1

[account42 → ivanbakel]

> IRC, path pieces in HTTP urls are not meant to be case-sensitive, and browsers have historically tried to "help" by re-casing URLs.

That would break with any webserver that is serving files from a case-sensitive filesystem. Which is most of them.

[Deadron → account42]

Windows....enough said.

[pretzelhands → Cthulhu_]

They're not the prettiest sight, yes, but I think anyone who isn't in some way a geek particularly cares about what's actually in URLs.

There's a reason why Apple got away with only showing the hostname of a URL: It doesn't matter to ordinary people. :)