Les ID de backend doivent-ils être publics ou non sur une API REST?

14

Basé sur ce que dit ce type: http://toddfredrich.com/ids-in-rest-api.html

Supposons qu'il ait raison d'utiliser UUID pour identifier les ressources de l'API. Ensuite, je rencontre des problèmes pour essayer de l'implémenter de cette façon, c'est:

class FooEntity {

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

(Entre le client et le serveur, sont envoyés et reçus des DTO, pas des entités de base de données.)

Le problème est que ce idn'est pas utile car je ne l'utilise plus. Le client fait les demandes uidalors pourquoi est-ce que je me donne la peine de gérer 2 identifiants? Ensuite, nous revenons à la même question du début. Si j'ai défini UUID comme clé primaire ( _id), j'expose l'ID du backend au public.

À côté de cela, il y a le sujet de l'efficacité. J'ai lu que l'indexation par ObjectId est beaucoup plus efficace que UUID.

database api-design mongodb

— anat0lius
source

7

J'expose l'ID du backend au public

De quels autres moyens disposez-vous pour identifier vos entités lors de leur retour via une demande? C'est parfaitement légitime et plus sûr que le SSN ou des identifiants similaires. C'est ce dont parle Todd - rendre la technologie d'identification et l'entité neutre et il a raison.

Sujet efficacité

Vous pouvez conserver les deux identifiants si ObjectId est vraiment beaucoup plus efficace. Théoriquement, il est toujours préférable d' utiliser les UUID pour les identifiants que les incrémenteurs automatiques de base de données.

— civan
source

Vous avez raison d'exposer l'ID. Concernant l'efficacité, je ne vois toujours pas comment utiliser les deux identifiants. Si le client fait une demande avec uuid, alors je vais faire une recherche sur le champ uuid et obtenir le résultat. Je ne peux pas connaître l'objetid jusqu'à ce que je récupère l'entité. Je suppose donc qu'il est inutile d'utiliser les deux.

— anat0lius

1

Cela pourrait avoir un sens pour le support hérité. Disons que l'ancien identifiant autonumérique est toujours référencé par les données ou les systèmes hérités. Sinon, il est parfaitement possible de travailler uniquement avec UUID

— Laiv

1

En réponse à votre question " De quels autres moyens disposez-vous pour identifier vos entités lorsqu'elles sont renvoyées via une demande? ", Des identifiants proxy par session. " La meilleure protection consiste à éviter d'exposer des références d'objet directes aux utilisateurs en utilisant un index, une carte de référence indirecte ou une autre méthode indirecte facile à valider "

— Peter Taylor

5

Non, en ce qui concerne la base de données, rien sur la structure interne n'est exposé à l'API externe. Les pièces d'identité n'ont aucune intelligence. Ils ne sont même pas uniques dans le monde réel. ID: 47 est partout. Il y a des entités auxquelles vous avez accès et que vous pouvez éventuellement manipuler les données, mais que cette base de données stocke tout dans une table ou dix, utilise un ID incrémentiel comme PK et se rapporte à un FK, vous ne le saurez jamais.

Si vous le pouvez, GetUserAccountByID (12345) demande simplement à quelqu'un d'essayer GetUserAccountByID (12346). Même si cela ne fonctionnera pas en raison d'autres mesures de sécurité, n'essayez même pas et n'essayez pas de pirater la société en demandant des informations sur le compte: 12346. À moins d'appeler le DBA et d'être prêt à attendre 2 semaines pour un réponse;)

Créez donc les GUID comme bon vous semble ou toute autre clé naturelle comme un numéro de téléphone ou une adresse e-mail. Mettez une contrainte unique sur le champ dans la table pour éviter une tentative de copier-coller obscure lors d'une tentative de fusion de données.

Ce n'est pas redondant. Les deux domaines ont des objectifs différents.

— JeffO
source

0

À propos de l'efficacité ID vs UUID, sauf si vous avez plusieurs jointures impliquant plusieurs tables ayant chacune des millions d'enregistrements, cela ne fera pas beaucoup de différence. L'utilisation de l'UUID rend votre application beaucoup plus difficile à éliminer si vous ne cochez pas / n'appliquez pas directement du côté du serveur.

GET [...] / 1
OBTENIR [...] / 2

C'est très facile lorsque vous utilisez ID, si vous utilisez plutôt UUID, c'est une option de moins pour un scrapper.

L'ID peut être considéré comme quelque chose d'internes à l'instance de base de données de votre application. Il y a trois mots importants dans cette phrase:

Application: puisque c'est votre modèle, il est probable que vos tables ne soient utilisées que par cette application
Base de données: si plusieurs applications l'utilisent contre la même base de données, tout va bien
Instance (de la base de données): si vous avez un système distribué, id se confondra entre eux, et ils n'auraient aucun sens pour tout autre système / application qui n'utilise pas l'instance de votre base de données. UUID est la solution pour ce cas spécifique.

Sur une préférence personnelle: je préfère avoir un identifiant simple et un identifiant professionnel unique (mail, login, ...). Donc, si je dois échanger des données, j'utiliserai l'ID d'entreprise, car le système cible peut ne pas gérer l'UUID, mais il va très probablement (ne jamais dire jamais ...) gérer correctement une clé d'entreprise unique.

— Walfrat
source