Closed xdoo closed 9 years ago
Die Restpunkte sind komplett funktional (z.B: mit Relation hinzufügen, HATEOAS, GET
POST
PATCH
und PUT
):
Möglichkeit 1: Hiding certain Repositories mit @RepositoryRestResource(exported = false)
Die allgemeine Ausgabe wird dann trotzdem Sichtbar sein, jedoch werden die Endpunkte für die annotierten Repositorys nichtmehr erstellt.
Möglichkeit 2: Overriding Response Handlers
Die von Spring generierte API wird hier weitgehend verwendet, nurnoch anpassungen werden vorgenommen.
Sind die Endpunkte abgesichert?
Möglichkeit 1: Was meinst du mit "allgemeine" Ausgabe?
Möglichkeit 2: Verstehe ich nicht. Kannst du das etwas mehr umschreiben :)
Die Endpunkte sind nur mit der initialen authentifizierung abgesichert. Rollen und Rechte kennen die Repositories nicht.
Mapped "{[/{repository}/{id}/{property}],methods=[GET],params=[],headers=[],consumes=[],produces=[],custom=[]}"
steht dann trotzdem da, es werden aber keine Endpunkte mehr erzeugt falls alle mit der Annotation abgesichert sind.Möglichkeit 2 Spring Data Rest erstellt automatisch einen Controller über alle Entitäten, Relationen, HATEOAS... der funktioniert auch ootb schon (Siehe Screenshot: URL ist /buergers/... also nicht von unserem Controller)
Man könnte diesen vorgenerierten Controller in Struktur so übernehmen und entsprechende endpunkte überschreiben (Rechte und Rollen hinzufügen, Logic, usw... ).
Im Englischen ist Plural immer ein s. Wie schön einfach kann die Welt sein :)
Ich halte von Möglichkeit 2 nicht viel, da es die Datenstrukturen der DB direkt in die Schnittstelle durch reicht. Eine Änderung im DB Modell schlägt sich gleich als Änderung in der API nieder. Die Schnittstellen sollten aber möglichst stabil gehalten werden. Auch ist die Granularität nicht immer deckungsgleich. Beispielweise sollte die Rest Schnittstelle bei einer 1:1 Beziehung (z.B, Wohnung/Adresse) EIN Objekt zurück geben, das beide Entiräten representiert.
Wenn man diese Probleme aus 2 ausbaut, dann würde ich rein gefühlsmäßig sagen, dass von den anfänglichen Vorteilen nicht mehr viel übrig bleibt.
Ich tendiere immer noch zu Möglichkeit 1 mit den Annotations.
Möglichkeit 3:
Die Dependency für Spring Data Rest entfernen, da sie sowieso nicht genutzt wird.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-rest</artifactId>
</dependency>
Dann werden auch keine Meldungen mehr angezeigt.
Features
- Supports JPA, MongoDB, Gemfire, and Neo4J Repositories
- Create new entities (auto-generated or pre-assigned IDs are both supported) using POST
- Update existing entities using PUT and PATCH
- Delete entities using DELETE
- Manage entity relationships using POST, PUT, DELETE
- Discover services and get or list available entities using GET
- Search entities through Repository query methods using GET
- Validate entities with JSR-303 or Spring Validator beans
- Extend the REST exporter's functionality by capturing ApplicationEvents
- Configure path and rel values using annotations or DSL config helper
- Page large results sets
- Sort results
- Use metadata (ALPS) to discover transitions and other details about the service
- Projection alternate views of data and pick excerpt options to make certain ops more efficient
Hört sich nach einer guten und pragmatischen Lösung an :)
Ohne die Spring Data Rest dependency funktionieren die Tests für POST
nichtmehr.
Dann einfach die Dependency auf
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-rest</artifactId>
<scope>test</scope>
</dependency>
setzen. Das sollte ausreichen.
Laut LOG werden Rest Endpunkte auf die Repositories erzeugt:
Es muss geprüft werden, ob das ein Sicherheitsrisiko ist und ob wir dieses Feature benötigen. Ich tendiere dazu, es abzuschalten.