Gli ID back-end devono essere pubblici o meno su un'API REST?

Sulla base di ciò che dice questo ragazzo: http://toddfredrich.com/ids-in-rest-api.html

Supponiamo che abbia ragione sull'UUID per identificare le risorse API. Quindi ho riscontrato problemi nel tentativo di implementarlo in questo modo, questo è:

class FooEntity {

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

(Tra client e server, vengono inviati e ricevuti DTO, non entità di database.)

Il problema ora è che idnon è utile in quanto non lo sto più usando. Il client effettua le richieste, uidquindi perché mi preoccupo di gestire 2 ID? Quindi torniamo allo stesso numero dell'inizio. Se imposto UUID come chiave primaria ( _id), espongo l'id back-end al pubblico.

Oltre a ciò, c'è l'argomento dell'efficienza. Ho letto che l'indicizzazione di ObjectId è molto più efficiente di UUID.

Sto esponendo l'ID backend al pubblico

Quali altri mezzi devi identificare le tue entità quando vengono restituite attraverso una richiesta? È perfettamente legittimo e sicuro rispetto a SSN o identificatori simili. Questo è ciò di cui parla Todd: rendere neutre la tecnologia delle identificazioni e l'entità ed ha ragione.

Argomento di efficienza

Puoi conservare entrambi gli identificatori se ObjectId è davvero molto più efficiente. Teoricamente è sempre meglio usare UUID per identificatori che auto-incrementatori di database.

No, per quanto riguarda il database, nulla sulla struttura interna è esposto all'API esterna. Gli ID non hanno intelligenza. Non sono nemmeno unici nel mondo reale. ID: 47 è ovunque. Ci sono entità a cui hai accesso e possibilmente puoi manipolare i dati, ma se questo database memorizza tutto in una tabella o dieci, utilizza un ID incrementale come PK e si riferisce a un FK, non lo saprai mai.

Se riesci, GetUserAccountByID (12345) sta semplicemente chiedendo a qualcuno di provare GetUserAccountByID (12346). Anche se non funzionerà a causa di altre misure di sicurezza, non provare nemmeno a tentare di hackerare la società chiedendo informazioni sull'account: 12346. A meno che tu non chiami il DBA e sia disposto ad aspettare 2 settimane per un reponse;)

Quindi crea i GUID come preferisci o qualsiasi altra chiave naturale come un numero di telefono o un indirizzo e-mail. Inserire un vincolo univoco sul campo nella tabella per evitare alcuni tentativi oscuri di copia e incolla in alcuni tentativi di unione dei dati.

Questo non è ridondante. I due campi hanno scopi diversi.

A proposito di id di efficienza vs UUID, a meno che tu non abbia un join multiplo che coinvolge più tabelle ciascuna con milioni di record, questo non farà molta differenza. L'uso di UUID rende l'applicazione molto più difficile da scartare se non si controlla / si applica direttamente sul lato server .:

• OTTIENI [...] / 1
• OTTIENI [...] / 2

È molto semplice quando si utilizza ID, se si utilizza UUID, è un'opzione in meno per uno scrapper.

L'ID può essere visto come qualcosa di interno all'istanza del database dell'applicazione. Ci sono tre parole importanti in quella frase:

• Applicazione: poiché è il tuo modello, è probabile che le tue tabelle vengano utilizzate solo da quell'applicazione
• Database: se più applicazioni lo hanno utilizzato sullo stesso database, stai bene
• Istanza (del database): se si dispone di un sistema distribuito, l'id sarà in conflitto tra loro e sarebbero privi di significato per qualsiasi altro sistema / applicazione che non utilizza l'istanza del database. UUID è la soluzione per quel caso specifico.

Su una preferenza personale: preferisco avere un ID semplice e un ID aziendale univoco (posta, accesso, ...). Quindi, se devo scambiare dati, userò l'ID aziendale, perché il sistema di destinazione potrebbe non gestire l'UUID, ma molto probabilmente (mai dire mai ...) gestirà bene una chiave aziendale univoca.