Warum sollten laut Konvention DB-Tabellennamen Singular sein, RESTful-Ressourcen jedoch Plural?

Es ist eine ziemlich etablierte Konvention, dass Namen von Datenbanktabellen, zumindest in SQL, Singular sein sollten. SELECT * FROM user;Siehe diese Frage und Diskussion .

Es ist auch eine ziemlich etablierte Konvention, dass RESTful API-Ressourcennamen im Plural sein sollten. GET /users/123und POST /userssieh dir das an .

In der einfachsten datenbankgestützten API ist der Name der Ressource in der URL die Tabelle, und die Datenelemente in der URL und den Anforderungs- / Antwortkörpern werden direkt den Spalten in der Datenbank zugeordnet. Konzeptionell sehe ich keinen Unterschied zwischen der Arbeit mit den Daten über diese theoretische API und der Arbeit direkt über SQL. Und deswegen macht der Unterschied in den Namenskonventionen zwischen userund für usersmich keinen Sinn.

Wie kann der Unterschied in der Pluralisierung gerechtfertigt werden, wenn REST-API und SQL konzeptionell dasselbe tun?

Die REST-Spezifikation (unabhängig von der gewünschten Ebene) wurde nicht als Datenbankzugriff konzipiert. Es wird versucht, den API-Zugriff zu standardisieren. Die genannten SQL-Konventionen (ob Sie sie verwenden möchten oder nicht) wurden nicht für den API-Zugriff entwickelt. Sie dienen zum Schreiben von SQL-Abfragen.

Das Problem beim Entpacken ist daher das konzeptionelle Verständnis, dass eine API direkt der Datenbank zugeordnet wird. Wir können dies zumindest bis ins Jahr 2009 als Anti-Pattern bezeichnen .

Der Hauptgrund dafür ist schlecht? Der Code mit der Beschreibung "Wie wirkt sich dieser Vorgang auf meine Daten aus?" wird Client-Code .

Dies hat einige schreckliche Auswirkungen auf die API. (keine vollständige Liste)

Dies erschwert die Integration in die API

Ich stelle mir die Schritte zum Erstellen eines neuen Benutzers folgendermaßen vor:

1. POST /users { .. }
2. POST /usersettings { .. } mit einigen Standardwerten
3. POST /confirmemails { .. }

Aber wie gehen Sie mit einem Fehler in Schritt 2 um? Wie oft wird dieselbe Logik für andere Clients Ihrer API kopiert?

Diese Datenoperationen sind auf der Serverseite oft einfacher zu sequenzieren, während sie vom Client als einzelne Operation initiiert werden. Eg POST /newusersetup. DBAs erkennen dies möglicherweise als gespeicherte Prozedur, die API-Operation hat jedoch möglicherweise Auswirkungen, die über die Datenbank hinausgehen.

Das Sichern der API wird zu einem schwarzen Loch der Verzweiflung

Angenommen, Sie müssen zwei Benutzerkonten zusammenführen.

1. GET /users/1
2. PUT /users/2 { .. }
3. DELETE /users/1

Wie richten Sie eine Benutzerberechtigung ein, um die Zusammenführungsfunktion zuzulassen, ohne das Löschen von Benutzern zuzulassen? Ist das Löschen eines Benutzers überhaupt angemessen, DELETE /users/1wenn es /usersettingsauch existiert?

API-Vorgänge sollten als Vorgänge auf höherer Ebene (als Datenbankvorgänge) betrachtet werden, die zu mehreren Änderungen im System führen können.

Wartung wird schwieriger

... weil Ihre Kunden von Ihrer Datenbankstruktur abhängig sind.

Basierend auf meinen Erfahrungen mit diesem Szenario:

• Sie können vorhandene Tabellen / Spalten nicht umbenennen oder entfernen. Auch wenn sie aufgrund ihrer Funktion falsch benannt sind oder nicht mehr verwendet werden. Kunden werden brechen.
• Neue Features können vorhandene Datenstrukturen nicht ändern. Daher werden Daten und Funktionen häufig künstlich getrennt, auch wenn sie ganzheitlich zu einem vorhandenen Feature gehören.
• Die Codebasis wird aufgrund von Fragmentierung, verwirrenden Namen und Gepäckresten, die nicht sicher entfernt werden können, nach und nach schwieriger zu verstehen.
• Alle bis auf triviale Änderungen werden immer riskanter und zeitaufwändiger.
• Das System stagniert und wird schließlich ersetzt.

Stellen Sie Ihre Datenbankstruktur nicht direkt Clients zur Verfügung, insbesondere Clients, über die Sie keine Entwicklungskontrolle haben. Verwenden Sie eine API, um den Client auf nur gültige Operationen einzugrenzen.

Wenn Sie also eine API nur als Schnittstelle direkt in eine Datenbank verwenden, ist die Pluralisierung die geringste Sorge. Abgesehen von einem Einwegexperiment würde ich vorschlagen, einige Zeit damit zu verbringen, die übergeordneten Operationen zu bestimmen, die die API darstellen soll. Und wenn Sie es so betrachten, gibt es keinen Konflikt zwischen pluralisierten API-Entitätsnamen und singulären SQL-Entitätsnamen. Sie sind aus verschiedenen Gründen da.

REST API und SQL machen NICHT "dasselbe"

Das OP fragt:

Wie kann der Unterschied in der Pluralisierung gerechtfertigt werden, wenn REST-API und SQL konzeptionell dasselbe tun?

Ah, aber Heuschrecke, es mag so aussehen , als ob die RESTful-Schnittstelle und die SQL-Tabellen "dasselbe tun", aber eine gute Programmierhygiene sagt uns, dass es immer eine Zwischenschicht gibt, die zwischen der REST-API und der Datenbank vermittelt. Diesen Punkt zu ignorieren bedeutet, vom Weg zur Softwareaufklärung abzuweichen! :)

So können RESTful-APIs und SQL-Tabellen problemlos ihren eigenen idiomatischen Namenskonventionen folgen, die an anderer Stelle gut dokumentiert und ausführlich besprochen werden.