3 ms·
Ask HN: UUIDs vs. Human-Readable IDs in APIs?
How do you think about when to use machine-generated IDs (such as UUIDs) versus human-readable IDs (such as Github organization / repo names)?
I'm specifically thinking about when to use these different types of IDs in APIs, API routes, and in your database. Assume that we could enforce uniqueness for human-readable IDs on a global or tenant basis.
- cratermoon 4y agoIt's not an either/or question, it's a "what is your use case?" question. Why do they need to be human-readable? If there are security aspects, you need quality cryptographically-strong randomness as well as unguessability.
- emschwartz 4y agoThe use case is a multi-tenant application where each organization has a set of plugins or integrations. Those integrations have associated config objects and maybe some other properties. Each organization might have some other resources that users create. It seems somewhat nice to have resources that users create and interact with via an API + CLI to use identifiers that people can type out and remember instead of copying. Unguessability isn't a big deal because all of these IDs can be namespaced under the organization ID and the auth check can just return a 404 instead of a 401/403 if the person doesn't have access.
- verdverm 4y agoWhy not support both ID versions pointing at a single resource?
- emschwartz 4y agoGood question. I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use to refer to things. It seems slightly more complicated to explain to users that there are these two ways to refer to things. There's also the issue (or benefit) of keeping the UUID the same if you are able to change the human-readable ID.
- verdverm 4y agoIt's not so different from users, ids, and display names
- cratermoon 4y agoIn that case, you're going to run into the same problem that happens with any organizational naming: names aren't stable. Reorgs happen. Buyouts happen. Rebranding happens. Even people's names change. Anyone who has ever worked at a moderately-sized company that got bought or renamed, knows the hell of The Renaming. And there's always things left out. Are you going to go through and change all package names in your code? Or are you going to be left with a fragile bit of tribal knowledge or obscure documentation explaining what "oldname" means everywhere? And don't even get me started on auth checks and someone spoofing the system because something still accepts the old identifier long after the original owner gave it up and some malicious party grabs it.
- verdverm 4y agoThis has nothing to do with the user's question. What you describe is at the code level naming patterns, what OP is asking about is database columns, and fairly standard queries at that.
- cratermoon 4y agoThe Naming Problem applies, I just used package names as an example. How many times have you seen a network, computer, project, or whatever named for something that no longer exists? The OP mentioned "Github organization / repo names" specifically. I know of github repos that are less than a year old and already refer to teams that don't exist any more. I presumed that's what was meant by "human readable IDs". Now if the "human readable" just means something like "pronounceable words", well, the only problem is no matter what language is chosen for those words, there will likely be someone who doesn't know what they mean, so they are just gibberish anyway.
- stop50 4y agoUuids have next to no chance for duplicates and are safe for usage in all languages. integers can cause problems if your system that use the numeric ids use the wrong type. you can run into this with javascript, which can cause problems. Integers can also cause problems with databases, mysql splits the space of possible ids between all servers in a cluster. So when one db server is more used for creating records you are wasting space. integers can also create problems if the datatype is too small.
- smt88 4y agoBoth. UUIDs require much less storage/memory than string keys, and you can create offline bulk inserts quickly and easily with them. Make your table with UUIDs as the primary keys, and then create a unique, human-readable lookup key as an additional column. This gives you the best of both worlds.
- emschwartz 4y agoThanks! That’s what we’ll do :)
- wizwit999 4y agoBase 64 encoded UUID's, like Stripe?
- emschwartz 4y agoThat's what we are currently doing. It's URL-safe but impossible to remember or type out so you need to copy the IDs around.