Should backend IDs be public or not on a REST API?

Question

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.

Answer 1

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.

Answer 2

No, as far as the database goes, nothing about the internal structure is exposed to the outside API. ID's have no intelligence. They're not even unique in the real world. ID: 47 is everywhere. There are entities you have access to and possibly can manipulate the data, but whether this database stores everything in one table or ten, uses incremental ID as PK and relates to an FK, you'll never know.

If you can GetUserAccountByID(12345) is just asking for someone to try GetUserAccountByID(12346). Eventhough it won't work due to other security measures, don't even try and don't try to social hack the company by asking for information on Account: 12346. Unless you call the DBA and are willing to wait 2 weeks for a reponse;)

So create the GUIDs however you see fit or any other natural key like a phone number or email address. Put a unique constraint on the field in the table to avoid some obscure copy and paste attempt in some merge data attempt.

This is not redundant. The two fields serve different purposes.

Answer 3

About efficiency id vs UUID, unless you have multiple join involving multiple table each having millions of record, this won't do that much of difference. Using UUID make your application much more difficult to scrap if you don't check/apply right on the server side.:

• GET [...]/1
• GET [...]/2

It's very easy when using ID, if you use UUID instead, it's one less option for a scrapper.

ID can be seen as something to internal to your application's database instance. There are three important words in that sentence :

• Application : since it's your model it is likely that your tables are only used by that application
• Database : If multiple application used it against the same database, you're sitll fine
• Instance (of the database) : if you have a distributed system, id will conflic with each others, and they would be meaningless for any others system/application that doesn't use your database's instance. UUID is the solution for that specific case.

On a personal preference : I prefer to have a simple ID and a unique business ID (mail, login, ...). So if I have to exchange data I will use the business ID, because the target system may not handle UUID, but he will very likely (never say never...) handle fine a unique business key.