First, I think that exposing the real db id is NOT good idea, am I right?
It depends.
If your object IDs come from a predictable sequence, that means someone using your application can guess likely valid IDs, and add them to URLs, POST requests etc.
If the objects are accessed read-only and publicly, then there is no problem at all just exposing the database as it was generated.
If you need to secure access, there is more than one way to do so. If you have secure authorisation in your web application, and can tell whether a current user should be able to see an object or not, then you already have sufficient security. Creating unguessable object ids (e.g. uuids) does not really help you. Using some other sequence to "hide" the id does not really add any security and could be a lot of work. Although you could go a step further and generate friendly URLs derived from other content (title), and that would be a similar effort, that is generally not a security concern.
You should only worry about exposing your DB ids directly if that would give a direct link via the API where unauthorised users could guess other IDs and access or change things they were not supposed to. If you cannot restrict access direct via the ID due to other constraints in the system, the answer is not to generate some other direct, predictable index to the same object (which will have the same problems with people being able to guess it), but do one of:
1) provide indirect access - e.g. user can only choose from objects that you have pre-selected for them, and you assign IDs to those choices instead, and only accept those choice_ids via your API, never the database ids of the objects being chosen.
2) generate unguessable IDs, possibly temporary, like SecureRandom.uuid