Q:

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

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. 

A:

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.

A:

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.

