Because in SPAs if a user creates new entities it can be easier to generate the UUIDs client side.

So then just a simple validation server side to ensure the data isn't malicious.

Never trust the client.

Yeah, you can require them to generate a UUID if it helps for your app (e.g. bulk create objects with relationships between them) but then on the server you can generate new UUIDs and return a mapping from old->new to the client.

If UUIDv4 was all that ever existed, there would be no need to validate anything apart of the fact that it's supposed to contain 32 hexadecimal characters.

All other versions, including the new v7, attach meaning to certain bits of the identifier. That cat has been out of the bag for a long time, so now everyone needs to maintain code to ensure that some rogue node doesn't spew back-dated identifiers belonging to the wrong department.

UUIDv4 attaches meaning to certain 6 or 7 bits (depending on a variant) of the identifier. UUIDv4 is a UUID after all.

UUIDv4 also contains some bits with meaning. But joke's on them, I tend to even randomize the version bits and call it UUIDv0.

I’d assume the validation is parsing the uuid with a uuid library (to decode it), and the library eagerly validates the version field, either to check for garbage or because it wants to yield a different subtype for each version.

but why decode it at all, if it's meant to be opaque?

I think there are a couple minor problems:

- if the ID is intended to be opaque then the vendor shouldn't document it as a UUID, as this changing to a different format would be a breaking change

- if the customer isn't going to process the subcomponents of the UUID then they should process it as an opaque string

- if the UUID library encounters a version number in a UUID it doesn't understand, it shouldn't reject the UUID but present it as an unstructured string.

After this blog post it seems likely that even Kite more customer will parse the IDs to extract time, since this has been documented.

Probably because a typed UUID avoids treating it like a random string, and decoding the UUID means you have 16 bytes per in memory rather than 36 (assuming usual 8-4-4-4-12 representation over the wire).