If you are implying that having an un-guessable URL secures your data, you might want to reconsider that approach. Your data should be secured server-side based on the actual auth in your app.

Not the OP but I read it as “much harder to scrape” than making it Secure. Which has some value.

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

You should not use your database identifiers in urls anyway.

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'

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.

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

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

Windows....enough said.

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. :)