Alternative to constrained long paths in URLs: nano-id / uuid

[joepio]

URL's are:

• always resolvable
• always unique
• often meaningful. But not always.

We often convey structure using URLs. In #556 , I introduced a way to make sure that the parent is present in the URL. This is useful, but can also lead to very long URLs for large content.

We could also allow new resources creates at /uuid or /nanoid as long as their path conforms to one of these specs.

With these random character IDs, we're sure that they are not meaningful, which means that users cant accidentally derive wrong information about them, or depend on their paths.

But I wonder - can we validate these ids so they are in fact random strings of characters? They will be created on the client.

In the case of NanoID, I don't think that's possible. That means evil-string999 is a valid nanoid.

UUID contains a dates encoded in it, so it always looks random.

are there other options?

Consideration

• This means that we can't find the parent resource by looking at the path. This has major implications for how fast we can resolve things / check rights.

[kod-kristoff]

If you require uniqueness, you must anyway check for that, since neither nanoid or uuid is guarenteed to be unique, only very unlikely, so given enough time and users with different PRNGs, you will get a collision.

Another option that I used is:
ulid are quite nice, lexicographical sortable and compact representation.

At least two implementations in rust:

• ulid
• rusty-ulid

[joepio]

Thanks @kod-kristoff, ulid sounds like a good alertenative!

And the uniqueness will always be enforced by the server (currently also by the client, but I think that is not worth it for 1 in a trillion checks failing)

[AlexMikhalev]

ULID allows sharding on different partitions in the store, which supports it, i.e. lexicographically sortable translates that ULIDS will be next to each other when partitioned using standard hashing algorithms.