I am not an expert in API designs, however, it feels like incremental id’s are a bad idea in an authenticated setting, users might just be able to change an id (to the next incremental value) and view information that they were not meant to see. I am sure you have probably thought of this, hence, is there a better design pattern I should employ? if so, could you give a brief example for completeness.
What you are referring to is called https://www.techopedia.com/definition/21985/security-through-obscurity-sto#:~:text=Security%20through%20obscurity%20(STO)%20is,or%20concealing%20its%20security%20flaws.
It’s not something you should employ on it’s own (or at all generally lol), if users should not be able to see something then you should implement proper security controls to prevent them from doing so such as route policies or conditional access, ect.
All of this is possible within Strapi, there is nothing wrong with incremental IDs other than size limits in certain databases which is a technical challenge that will not impact many.
For example the maximum signed id value in most SQL databases is 2,147,483,647 or unsigned is 4,294,967,295. In certain cases an ObjectID or UID would be better but not required.
Another good example of this is changing the SSH port on a Linux server from 22 to something else like say 2022 or 8022. It does absolutely nothing to help secure your server at all, it just makes it harder for novices to find it but a advanced engineer or bot will easily find it in seconds.
If you really don’t want to show IDs on something, write a route middleware that will loop through the response and delete the id field from the response before it’s sent. Shouldn’t impact performance too much.