REST API Design – Should Backend IDs Be Public?

api-designdatabasemongodb

Based on what this guy says: http://toddfredrich.com/ids-in-rest-api.html

Let assume he is right about using UUID to identify the api resources. Then I run into troubles trying to implementing it that way, this is: 

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

(Between client and server, are sent and received DTOs, not data base entities.)

The problem now is that id is not useful as I'm not using it anymore. The client makes the requests with uid so why do I bother to handle 2 id's ?
Then we get back to the same issue of the beginning. If I set UUID as the primary key (_id) then I'm exposing the backend id to the public.

Beside of that, there is the efficiency topic. I've read that indexing by ObjectId is much more efficient than UUID.

Best Answer

I'm exposing the backend id to the public

What other means do you have to identify your entities when they're returned through a request? That's perfectly legitimate and safer than SSN or similar identifiers. That's what Todd is talking about - making identifications technology and entity neutral and he's right.

Efficiency topic

You can keep both identifiers if ObjectId is really much more efficient. Theoretically it's always better to use UUIDs for identifiers than database auto incrementers.

Related Topic