Ich habe eine MySQL DB und eine SpringBoot-Anwendung auf Tomcat ausgeführt. Dies ist ein persönliches Projekt von mir und meine erste Erfahrung beim Entwurf von REST-Diensten. Ich habe versucht, meine POJOs zu erstellen, um der Datenbank zu entsprechen, aber dieses bestimmte Objekt verursacht einige Zweifel.Spring REST API Antwort für Junction-Tabellen
Hier sind die primären Datenbanktabellen:
- Spieler (id, Beschreibung)
- Kampagne (id, Beschreibung)
- Ressource (ID, Beschreibung, resource_type_id)
- RESOURCE_TYPE (id, Beschreibung)
- Komponente (id, Beschreibung)
... und folgende Kreuzung Tabellen:
- player_resource (id, player_id, RESOURCE_ID): Ein Spieler kann viele Ressourcen haben, und eine Ressource kann zu vielen Spielern gehören.
- campaign_resource (id, campaign_id, resource_id): Eine Kampagne kann viele Ressourcen haben und eine Ressource kann zu vielen Kampagnen gehören.
- resource_component (id, RESOURCE_ID, component_id): eine Ressource viele Komponenten zu viele Ressourcen haben können, und eine Komponente kann gehören
Ich bin irgendwie verloren, wie soll ich meine JSON-Antwort werden die Gestaltung und die entsprechenden POJO (s) für das Ressourcenobjekt speziell.
Was ich denke, ist bisher drei separate URI zu haben:
- .../api/resources/{uuid}: Gibt die spezifischen Ressourcen.
- .../api/campaigns/{uuid}/resources: Gibt zurück, welche Ressourcen in der bereitgestellten Kampagne verfügbar sind. Abgesehen davon existieren Spieler im Rahmen einer Kampagne, so dass diese bestimmte API schließlich bestimmt, was ein Spieler im Laufe seiner Existenz erhalten kann.
- .../api/players/{uuid}/resources: Gibt zurück, welche Ressourcen der Spieler derzeit in seinem Inventar hat.
habe ich eine einzige POJO für Ressource:
public class Resource {
private String resourceId;
private String shortDescription;
private String longDescription;
private ResourceType resourceType;
private List<Component> components;
// getters and setters
}
Ich habe zwei weitere POJOs für CampaignResource und PlayerResource:
public class CampaignResource {
private String campaignResourceId;
private Resource resource;
// getters and setters
}
public class PlayerResource {
private String playerResourceId;
private Resource resource;
// getters and setters
}
Ich erwarte, dass die gleiche URI # 1 und # 2 zurück Layout, aber ich habe Bedenken hinsichtlich der Redundanz mit URI # 3. URI # 2 kann zehn Ressourcen zurückgeben, was gut ist und erwartet wird, aber URI # 3 könnte Hunderte zurückgeben, abhängig davon, was ein Spieler herumträgt.
Die einzigen Informationen, die ich wirklich brauche, wenn ich URI # 3 anrufe, sind die Felder playerresource_id, resource_id und resource_type_id. Ich muss nicht wissen, welche Komponenten eine Ressource umfassen, da diese Informationen in einer viel überschaubareren Weise zurückgebracht werden, entweder unter Verwendung von URI # 1 oder URI # 1.
Ich habe Angst, separate "Basis" Resource POJOs zu erstellen, da ich mich verpflichtet fühle, irgendeiner Form der kanonischen Modellierung zu folgen. Könnte ich etwas wie eine JsonView verwenden und Resource RowMappers basierend darauf, ob es URI # 1, # 2 oder # 3 ist? Ich könnte irgendeine Art von Paging implementieren, aber es sind immer noch viele redundante Daten vorhanden. Wie würde ein erfahrener REST-Entwickler das angehen?
Das ist für meine Arbeit nicht werden .../api/Spieler/{uuid}/Ressourcen nennen, weil ich das playerResourceId Feld zurückkehren müssen, die die Kreuzung Schlüssel für die player_resource Tabelle enthält. Ein Spieler kann viele gleiche Ressourcen haben, also konnte ich ohne playerResourceId keine eindeutige Instanz von Resource identifizieren. – glang
Ihr Rest-Call-Vertrag besagt, dass Ressourcen für einen bestimmten Spieler zurückgegeben werden, der durch seine UUID identifiziert wird. Der Anrufer sollte sich nicht für playerResourceId interessieren. Durch das Aussetzen von playerResourceId verschütten Sie Ihren Datenbankentwurf an den externen Anrufer. Was ist, wenn Sie später entscheiden, die Junction-Tabelle nicht für Ihre Player-zu-Ressource-Zuordnung zu verwenden, sondern normalisieren und Ressourcen-UUID in die Player-Tabelle einfügen, welche playerResourceId werden Sie zurückgeben? – tsolakp
Es müsste immer noch ein Schlüssel vorhanden sein, um die spezifische Instanz einer Ressource zu identifizieren. Beispiel: Wenn ich eine Ressource 'Holz' habe und mein Spieler zwei 'Holz' Ressourcen hat, muss ich etwas verwenden, um die beiden zu unterscheiden. Gibt es einen besseren Weg als die Verwendung einer UUID? – glang