it-swarm.com.de

Sollten Backend-IDs auf einer REST API) öffentlich sein oder nicht?

Basierend auf dem, was dieser Typ sagt: http://toddfredrich.com/ids-in-rest-api.html

Nehmen wir an, er hat Recht damit, UUID zur Identifizierung der API-Ressourcen zu verwenden. Dann habe ich Probleme, es auf diese Weise zu implementieren. Dies ist:

class FooEntity {

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

(Zwischen Client und Server werden DTOs gesendet und empfangen, keine Datenbankentitäten.)

Das Problem ist jetzt, dass id nicht nützlich ist, da ich es nicht mehr benutze. Der Client stellt die Anforderungen mit uid. Warum mache ich mir also die Mühe, zwei IDs zu verarbeiten? Dann kehren wir zum gleichen Thema des Anfangs zurück. Wenn ich UUID als Primärschlüssel festlege (_id) dann stelle ich die Backend-ID der Öffentlichkeit zur Verfügung.

Daneben gibt es das Thema Effizienz. Ich habe gelesen, dass die Indizierung mit ObjectId viel effizienter ist als die UUID.

14
anat0lius

Ich stelle die Backend-ID der Öffentlichkeit zur Verfügung

Welche anderen Mittel müssen Sie verwenden, um Ihre Entitäten zu identifizieren, wenn sie über eine Anfrage zurückgegeben werden? Das ist absolut legitim und sicherer als SSN oder ähnliche Kennungen. Das ist es, worüber Todd spricht - Identifikationstechnologie und Entität neutral zu machen und er hat Recht.

Effizienz-Thema

Sie können beide Bezeichner behalten, wenn ObjectId wirklich viel effizienter ist. Theoretisch ist es immer besser, IDs für Bezeichner zu verwenden als automatische Datenbankinkrementierer.

7
civan

Nein, was die Datenbank betrifft, ist nichts an der internen Struktur der externen API zugänglich. Ausweise haben keine Intelligenz. Sie sind nicht einmal einzigartig in der realen Welt. ID: 47 ist überall. Es gibt Entitäten, auf die Sie Zugriff haben und die möglicherweise die Daten bearbeiten können. Ob diese Datenbank jedoch alles in einer oder zehn Tabellen speichert, eine inkrementelle ID als PK verwendet und sich auf eine FK bezieht, wissen Sie nie.

Wenn Sie können, fordert GetUserAccountByID (12345) nur jemanden auf, GetUserAccountByID (12346) auszuprobieren. Obwohl es aufgrund anderer Sicherheitsmaßnahmen nicht funktioniert, versuchen Sie nicht einmal, das Unternehmen sozial zu hacken, indem Sie nach Informationen zu Konto: 12346 fragen. Es sei denn, Sie rufen den DBA an und sind bereit, 2 Wochen auf eine zu warten Antwort;)

Erstellen Sie also die GUIDs nach Belieben oder einen anderen natürlichen Schlüssel wie eine Telefonnummer oder eine E-Mail-Adresse. Legen Sie eine eindeutige Einschränkung für das Feld in der Tabelle fest, um einen unklaren Versuch des Kopierens und Einfügens bei einem Versuch, Daten zusammenzuführen, zu vermeiden.

Dies ist nicht redundant. Die beiden Felder dienen unterschiedlichen Zwecken.

5
JeffO

Informationen zur Effizienz-ID im Vergleich zur UUID: Wenn Sie nicht mehrere Verknüpfungen mit mehreren Tabellen mit jeweils Millionen Datensätzen haben, macht dies keinen großen Unterschied. Die Verwendung von UUID erschwert das Verschrotten Ihrer Anwendung erheblich, wenn Sie nicht direkt auf der Serverseite prüfen/anwenden:

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

Es ist sehr einfach, ID zu verwenden. Wenn Sie stattdessen UUID verwenden, ist dies eine Option weniger für einen Scrapper.

Die ID kann als intern für die Datenbankinstanz Ihrer Anwendung angesehen werden. Dieser Satz enthält drei wichtige Wörter:

  • Anwendung: Da es sich um Ihr Modell handelt, werden Ihre Tabellen wahrscheinlich nur von dieser Anwendung verwendet
  • Datenbank: Wenn mehrere Anwendungen sie für dieselbe Datenbank verwendet haben, ist dies in Ordnung
  • Instanz (der Datenbank): Wenn Sie ein verteiltes System haben, steht die ID in Konflikt miteinander und ist für jedes andere System/jede andere Anwendung, die die Instanz Ihrer Datenbank nicht verwendet, bedeutungslos. UUID ist die Lösung für diesen speziellen Fall.

Persönlich: Ich bevorzuge eine einfache ID und eine eindeutige Geschäfts-ID (Mail, Login, ...). Wenn ich also Daten austauschen muss, verwende ich die Geschäfts-ID, da das Zielsystem möglicherweise keine UUID verarbeitet, aber er wird sehr wahrscheinlich (niemals nie sagen ...) einen eindeutigen Geschäftsschlüssel verarbeiten.

0
Walfrat