Is there a way to make the ids on the urls less obvious?
Slugs? UUID? Any pointers? Will a migration damage existing implementations (app running fine with ids)? Then there is the final question about whether it is even a sensible idea – any special benefits in obscuring ids apart from added curiousity?
As someone who has done webscraping a lot, when i see some website that uses interger ids, i do some “testing” to see if the site has properly dealt with permission.
For example, i’m logged in as an customer, and i see on my url:
example.com/orders/1234/ then i try
example.com/orders/1233/, and if the website has been properly configured, you receive a 404 page and the curiosity is over.
As long as you are properly defining which user can see which entities, then there’s no big deal on using intergers ids.
Opinion: UUIDs on urls that is used by humans looks awful.
slugs or uuids (or combination of both) are usually a good idea, yes.
Making any decision along these lines are an architectural decision that should be made in the context of a risk assessment.
We use IDs - we’ve already had the need to provide row-level security throughout the system, so people guessing IDs don’t concern us.
There are some situations where hiding an ID may be beneficial, although those issues can usually be worked around. (For example, you could start the sequence at a value other than 1. You can also set an increment other than 1.)
Personally, I have an extreme dislike of using slugs for any content not managed by admins. If this is content being added as a result of external people performing actions on a site, you need to ensure that no slugs are duplicated.
UUIDs do work - even “shortened” UUIDs. However, using them may come with other performance implications.