streamalism.org

1. Introduktion

I denne vejledning overvejer vi en ny funktion i Spring MVC, der giver os mulighed for at specificere webanmodningerne ved hjælp af sædvanlige Java-grænseflader.

2. Oversigt

Normalt, når vi definerer en controller i Spring MVC, dekorerer vi dens metoder med forskellige kommentarer, der specificerer anmodningen: URL'en til slutpunktet, HTTP-anmodningsmetoden, stivariablerne og så videre.

Vi kan for eksempel introducere / gem / {id} slutpunkt ved hjælp af nævnte kommentarer på en ellers almindelig metode:

@PostMapping ("/ save / {id}") @ResponseBody public Book save (@RequestBody Book book, @PathVariable int id) {// implementering}

Naturligvis er dette slet ikke et problem, når vi kun har en controller, der håndterer anmodningerne. Situationen ændrer sig lidt, når vi har forskellige controllere med samme metodesignaturer.

For eksempel kan vi have to forskellige versioner af controlleren - på grund af migration eller lignende - der har samme metodesignaturer. I så fald ville vi have en betydelig mængde duplikerede annoteringer, der ledsager metodedefinitionerne. Det ville naturligvis være i strid med TØRRET (gentag ikke dig selv) -princippet.

Hvis denne situation ville finde sted for rene Java-klasser, ville vi blot definere en grænseflade og få klasserne til at implementere denne grænseflade. I controllerne, den største byrde for metoderne skyldes ikke metodens underskrifter, men på grund af metodens annoteringer.

Forår 5.1 introducerede dog en ny funktion:

Kontrollerparameterkommentarer registreres også på grænseflader: Tillader komplette kortlægningskontrakter i controllergrænseflader.

Lad os undersøge, hvordan vi kan bruge denne funktion.

3. Controllerens interface

3.1. Kontekstopsætning

Vi illustrerer den nye funktion ved hjælp af et eksempel på en meget enkel REST-applikation, der administrerer bøger. Den består af kun en controller med metoder, der giver os mulighed for at hente og ændre bøgerne.

I vejledningen koncentrerer vi os kun om de problemer, der er relateret til funktionen. Alle implementeringsproblemer i applikationen kan findes i vores GitHub-arkiv.

3.2. Interface

Lad os definere en almindelig Java-grænseflade, hvor vi ikke kun definerer metodernes signaturer, men også typen af ​​webanmodninger, de skal håndtere:

@RequestMapping ("/ standard") offentlig grænseflade BookOperations {@GetMapping ("/") Liste getAll (); @GetMapping ("/ {id}") Valgfri getById (@PathVariable int id); @PostMapping ("/ save / {id}") offentlig ugyldig gemme (@RequestBody Book book, @PathVariable int id); }

Bemærk, at vi muligvis har en kommentar på klasseniveau såvel som på metodeniveau. Nu kan vi oprette en controller, der implementerer denne grænseflade:

@RestController @RequestMapping ("/ book") offentlig klasse BookController implementerer BookOperations {@Override public List getAll () {...} @Override public Optional getById (int id) {...} @Override public void save (Book book , int id) {...}}

Vi skal stadig tilføje kommentaren på klasseniveau @RestController eller @Kontrol til vores controller. Defineret på denne måde arver controlleren alle kommentarer, der er relateret til kortlægningen af ​​webanmodningerne.

For at kontrollere at controlleren nu fungerer som forventet, lad os køre applikationen og trykke på getAll () metode ved at fremsætte den tilsvarende anmodning:

krølle // localhost: 8081 / book /

Selvom controlleren implementerer grænsefladen, kan vi finjustere den yderligere ved at tilføje webanmodninger. Vi kan gøre det på en måde, som vi gjorde det for grænsefladen: enten på klasseniveau eller på metodeniveau. Faktisk har vi brugt denne mulighed, når vi definerer controlleren:

@RequestMapping ("/ book") offentlig klasse BookController implementerer BookOperations {...}

Hvis vi tilføjer kommentarer til webanmodninger til controlleren, har de forrang for interfaceens. Med andre ord, Spring fortolker controllerens grænseflader på en måde svarende til, hvordan Java håndterer arv.

Vi definerer alle almindelige egenskaber for webanmodning i grænsefladen, men i controlleren kan vi altid finjustere dem.

3.3. Forsigtig Bemærk

Når vi har en grænseflade og forskellige controllere, der implementerer den, kan vi ende med en situation, hvor en webanmodning kan håndteres efter mere end en metode. Naturligvis vil Spring kaste en undtagelse:

Forårsaget af: java.lang.IllegalStateException: flertydig kortlægning.

Hvis vi dekorerer controlleren med @RequestMapping, kan vi reducere risikoen for tvetydige kortlægninger.

4. Konklusion

I denne vejledning har vi overvejet en ny funktion, der blev introduceret i foråret 5.1. Nu, når Spring MVC-controllere implementerer en grænseflade, gør de dette ikke kun på den almindelige Java-måde, men arver også alle webanmodningsrelaterede funktioner defineret i grænsefladen.

Som altid finder vi muligvis de tilsvarende kodestykker på vores GitHub-lager.