Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Use randomly generated IDs in the REST API #2187
Is your feature request related to a problem? Please describe.
I'm opening this ticket after having read this great article about data analysis on dev.to's articles.
The question I'd like to set forth, in preparation for a future "publication" of the API, is: should dev.to use randomly generated resource IDs instead of exposing "internal" autoincrementing integer primary keys or not?
A "classic" best practice in API design is not to expose internal details of your app, separating as much as possible how the data is organized from how is accessible from third parties.
Autoincrementing primary keys are usually discouraged in public APIs (by some, not by all) mainly for three reasons:
This is more a question of policy than a technical argument because, at least for the second of the three reasons, DEV is perhaps perfectly fine with that.
Some possible alternatives to auto incrementing integer primary keys:
My preference goes to one of the last two options
Describe the solution you'd like
Because the API is not public yet, and it's relatively small (only 8 controllers), I think that the transition would be doable if there's consensus on this. After publication and documentation it might be harder, especially because DEV is already a big community and developers are already jumping at the opportunity to use the API (hence the article ;))
For obvious reasons there shouldn't be a situation where both (integer IDs and alphanumeric IDs) would work at the same time. That would only strain the system (because it might result in two queries, instead of one).
The frontend/SPA would also need to be aligned and updated.
What do you think?
I did a quick tour of some public APIs (starting from those used by DEV itself and this is what I've found:
A few more:
Similar to KSUID is ObjectId that have been in use in MongoDB for a while.
A fun app is Twitter. They were originally based on Rails and used sequential IDs until they ran into scaling issues and needed to generate IDs on multiple servers at once. You can read about their fix. (I'm not advocating this as a solution, it's just interesting.)
Cool, seems based on the same principle, the ability to sort and extract time information.
Yeah that's a classic problem in distributed programming after passing a certain scale I guess, Snowflake is mentioned in the Segment article. Although DEV is probably a little away from having those scaling issues I think it would save a lot of pain down the line to guard against that