¿Los ID de fondo deben ser públicos o no estar en una API REST?

14

Según lo que dice este tipo: http://toddfredrich.com/ids-in-rest-api.html

Supongamos que tiene razón sobre el uso de UUID para identificar los recursos de la API. Luego me encuentro con problemas tratando de implementarlo de esa manera, esto es:

class FooEntity {

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

(Entre el cliente y el servidor, se envían y reciben DTO, no entidades de base de datos).

El problema ahora es que idno es útil ya que ya no lo estoy usando. El cliente realiza las solicitudes, uidentonces, ¿por qué me molesto en manejar 2 ID? Luego volvemos al mismo tema del principio. Si configuro UUID como la clave principal ( _id), entonces expongo el id del backend al público.

Además de eso, está el tema de la eficiencia. He leído que la indexación por ObjectId es mucho más eficiente que UUID.

database api-design mongodb

— anat0lius
fuente

7

Estoy exponiendo la identificación del backend al público.

¿Qué otros medios tiene para identificar sus entidades cuando son devueltas a través de una solicitud? Eso es perfectamente legítimo y más seguro que el SSN o identificadores similares. De eso está hablando Todd: hacer que la tecnología de identificación y la entidad sean neutrales y tiene razón.

Tema de eficiencia

Puede mantener ambos identificadores si ObjectId es realmente mucho más eficiente. Teóricamente, siempre es mejor usar UUID para identificadores que los incrementadores automáticos de bases de datos.

— civan
fuente

Tienes razón sobre exponer la identificación. Acerca de la eficiencia, todavía no veo cómo podría usar ambas identificaciones. Si el cliente realiza una solicitud con uuid, haré una consulta buscando en el campo uuid y obtendré el resultado. No puedo conocer el objectid hasta que recupere la entidad. Así que supongo que no tiene sentido usar ambos.

— anat0lius

1

Podría tener sentido para el soporte heredado. Digamos que la antigua identificación autonumérica todavía está referenciada por datos o sistemas heredados. De lo contrario, es perfectamente posible trabajar solo con UUID

— Laiv

1

En respuesta a su pregunta " ¿Qué otros medios tiene para identificar sus entidades cuando se devuelven a través de una solicitud? ", ID de proxy por sesión. " La mejor protección es evitar exponer referencias directas de objetos a los usuarios mediante el uso de un índice, un mapa de referencia indirecta u otro método indirecto que sea fácil de validar "

— Peter Taylor

5

No, en lo que respecta a la base de datos, nada sobre la estructura interna está expuesta a la API externa. Las identificaciones no tienen inteligencia. Ni siquiera son únicos en el mundo real. ID: 47 está en todas partes. Hay entidades a las que tiene acceso y posiblemente puede manipular los datos, pero si esta base de datos almacena todo en una tabla o diez, usa una identificación incremental como PK y se relaciona con un FK, nunca lo sabrá.

Si puede GetUserAccountByID (12345) solo está pidiendo que alguien pruebe GetUserAccountByID (12346). A pesar de que no funcionará debido a otras medidas de seguridad, ni siquiera intente y no intente hackear socialmente a la compañía solicitando información en la cuenta: 12346. A menos que llame al DBA y esté dispuesto a esperar 2 semanas por un respuesta;)

Cree los GUID como mejor le parezca o cualquier otra clave natural como un número de teléfono o una dirección de correo electrónico. Ponga una restricción única en el campo de la tabla para evitar algún intento oscuro de copiar y pegar en algún intento de fusión de datos.

Esto no es redundante. Los dos campos tienen diferentes propósitos.

— JeffO
fuente

0

Acerca de la identificación de eficiencia frente a UUID, a menos que tenga múltiples uniones que involucren múltiples tablas, cada una con millones de registros, esto no hará mucha diferencia. Usar UUID hace que su aplicación sea mucho más difícil de eliminar si no marca / aplica directamente en el lado del servidor .:

OBTENER [...] / 1
OBTENER [...] / 2

Es muy fácil cuando se usa ID, si usa UUID en su lugar, es una opción menos para un scrapper.

ID puede verse como algo interno a la instancia de la base de datos de su aplicación. Hay tres palabras importantes en esa oración:

Aplicación: dado que es su modelo, es probable que sus tablas solo sean utilizadas por esa aplicación
Base de datos: si varias aplicaciones la usaron contra la misma base de datos, está bien
Instancia (de la base de datos): si tiene un sistema distribuido, la identificación entrará en conflicto entre sí y no tendría sentido para ningún otro sistema / aplicación que no utilice la instancia de su base de datos. UUID es la solución para ese caso específico.

En una preferencia personal: prefiero tener una identificación simple y una identificación comercial única (correo, inicio de sesión, ...). Entonces, si tengo que intercambiar datos, usaré la ID comercial, porque el sistema de destino puede no manejar UUID, pero muy probablemente (nunca diga nunca ...) manejará bien una clave comercial única.

— Walfrat
fuente