Quando usare @RestController vs @RepositoryRestResource


87

Ho esaminato vari esempi di come utilizzare Spring con REST . Il nostro obiettivo finale è una HATEOAS/HALconfigurazione primaverile

Ho visto due metodi distinti per il rendering di REST in Spring

  1. Via @RestControllerall'interno di un controller

  2. Via @RepositoryRestResourceall'interno di un repository

La cosa che sto lottando per trovare è perché dovresti usarne uno sull'altro. Quando si cerca di implementare HALqual è il migliore?

Il nostro database backend è Neo4j .

Risposte:


61

Ok, quindi il racconto è che vuoi usare @RepositoryRestResourcepoiché questo crea un servizio HATEOAS con Spring JPA .

Come puoi vedere qui aggiungendo questa annotazione e collegandola al tuo Pojo hai un servizio HATEOAS completamente funzionante senza dover implementare il metodo del repository oi metodi del servizio REST

Se aggiungi il, @RestControllerallora devi implementare ogni metodo che vuoi esporre da solo e inoltre non lo esporta in un formato HATEOAS .


7
Per impostazione predefinita, Spring Data REST esporterà TUTTI i repository dell'interfaccia pubblica di primo livello. Hai solo bisogno di @RepositoryRestResource per NON esportare un'interfaccia o per modificare i dettagli dell'endpoint.
gregturn

4
Se usi RestController con Spring Data REST, eviterai TUTTO ciò che Spring Data REST fornisce. Per codificare un controller Spring MVC personalizzato che utilizza i convertitori di messaggi REST di Spring Data e così via, esaminare BasePathAwareController.
gregturn

Non penso che la risposta accettata sia corretta @gregturn ha la risposta migliore.
Marco

39

C'è una terza (e quarta) opzione che non hai delineato, che consiste nell'usare @BasePathAwareController o @RepositoryRestController, a seconda che tu stia eseguendo azioni specifiche dell'entità o meno.

@RepositoryRestResource viene utilizzato per impostare le opzioni sull'interfaccia pubblica del repository: creerà automaticamente gli endpoint in base al tipo di repository che viene esteso (ad esempio CrudRepository / PagingAndSortingRepository / ecc.).

@BasePathAwareController e @RepositoryRestController vengono utilizzati quando si desidera creare manualmente endpoint, ma si desidera utilizzare le configurazioni REST di Spring Data che sono state impostate.

Se usi @RestController, creerai un insieme parallelo di endpoint con diverse opzioni di configurazione - cioè un diverso convertitore di messaggi, diversi gestori di errori, ecc - ma coesisteranno felicemente (e probabilmente causeranno confusione).

La documentazione specifica può essere trovata qui .


6
Penso che questo non sia più vero. Se a @RestControllerutilizza lo stesso percorso di a @RepositoryRestResource, gli endpoint del repository non verranno creati.
Hubert Grzeskowiak

19

Bene, le risposte di cui sopra sono corrette nel loro contesto, ma ti sto ancora dando un esempio pratico.

In molti scenari come parte dell'API è necessario fornire endpoint per la ricerca di un'entità in base a determinati criteri. Ora usando JPA non devi nemmeno scrivere query, basta creare un'interfaccia e metodi con una nomenclatura specifica di Spring-JPA. Per esporre tali API, creerai il livello di servizio che chiamerebbe semplicemente questi metodi di repository e infine i controller che esporranno gli endpoint chiamando il livello di servizio.

Ciò che Spring ha fatto qui, ti consente di esporre questi endpoint da tali interfacce (repository) che generalmente sono chiamate GET all'entità di ricerca e in background genera i file necessari per creare endpoint finali. Quindi, se stai usando @RepositoryRestResource, non è necessario creare il livello Service / Controller.

D'altra parte @RestController è un controller che si occupa specificamente dei dati JSON e il resto funziona come controller. In breve @Controller + @ResponseBody = @RestController.

Spero che sia di aiuto.

Vedi il mio esempio di lavoro e il blog per lo stesso:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with -hibernate-no-controller


Posso vedere persone che visitano il mio blog, se questa soluzione funziona, per favore vota.
shaILU

10

@RepositoryRestController sovrascrivere i controller REST Spring Data generati di default dal repository esposto.

Per sfruttare le impostazioni REST di Spring Data, i convertitori di messaggi, la gestione delle eccezioni e altro, utilizzare l' @RepositoryRestControllerannotazione invece di un MVC Spring standard @Controllero@RestController

Ad esempio, questi controller utilizzano l' spring.data.rest.basePathimpostazione Spring Boot come percorso di base per il routing.

Vedere Sostituzione dei gestori di risposta REST di Spring Data .

Sii consapevole dell'aggiunta @ResponseBodyin quanto viene persa@RepositoryRestController

Se non hai esposto il repository (contrassegnato come @RepositoryRestResource(exported = false)), usa @BasePathAwareControllerinvece l'annotazione

Fai anche attenzione alle borse

ControllerLinkBuildernon prende in considerazione il percorso di base di Spring Data REST e @RequestMappingnon deve essere utilizzato a livello di classe / tipo

e

Il percorso di base non viene visualizzato in HAL

Soluzione alternativa per correggere il collegamento: https://stackoverflow.com/a/51736503/548473

AGGIORNAMENTO: finalmente preferisco non usarlo a @RepositoryRestControllercausa di molte soluzioni alternative.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.