uuid in doubt about http-api-design HOT 4 OPEN

It's worth mentioning that UUIDs also bring security benefits. An online store may leak information about their sales numbers if they expose integer IDs for their order numbers, allowing competitors to monitor their activity. Malicious actors may also use them to enumerate/scrape resources which may not be desirable. I'd personally recommend UUIDs over integers unless you expect to never expose these ids or have a good reason to use them.

from http-api-design.

It may indeed be worthwhile to amend this one slightly, even if only to make it clear that it's certainly not a slam dunk to use UUIDs.

The way I see it, UUID advantages:

• Operational errors, even across different tables/resources, are incredibly difficult to do by accident. Two different resources in two different tables might share the ID 23, but when it comes to UUIDs, no entity shares an ID with anything else in the database. This has legitimately saved me a couple times as I've run an UPDATE against the wrong table (again, accidentally).
• Scales well beyond a single master database.

Sequence/serial advantages:

• Much improved data locality in that new data will land in the same nodes in the B-tree/pages on disk. If you have a table with a lot of INSERTs happening, sequences will be far more performant I/O-wise.
• More human friendly in that it's easy to copy or remember a comparatively short integer ID compared to a UUID.

from http-api-design.

Good callouts. Do you think we should move from a recommendation to an explanation of the tradeoffs then?

from http-api-design.

I'd welcome a PR if you'd like to draft some updates.

from http-api-design.