streamalism.org

1. Introduksjon

I denne opplæringen vurderer vi en ny funksjon i Spring MVC som lar oss spesifisere nettforespørslene ved hjelp av vanlige Java-grensesnitt.

2. Oversikt

Vanligvis, når vi definerer en kontroller i Spring MVC, dekorerer vi metodene med forskjellige merknader som spesifiserer forespørselen: URL-en til sluttpunktet, HTTP-forespørselsmetoden, banevariablene og så videre.

Vi kan for eksempel introdusere / lagre / {id} sluttpunkt ved å bruke nevnte merknader på en ellers vanlig metode:

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

Naturligvis er dette ikke et problem i det hele tatt når vi bare har en kontroller som håndterer forespørslene. Situasjonen endres litt når vi har forskjellige kontrollere med samme metodesignaturer.

For eksempel kan vi ha to forskjellige versjoner av kontrolleren - på grunn av migrering eller lignende - som har samme metodesignaturer. I så fall vil vi ha en betydelig mengde dupliserte merknader som følger med metodedefinisjonene. Åpenbart vil det bryte med TØRKE (ikke gjenta deg selv) prinsipp.

Hvis denne situasjonen ville finne sted for rene Java-klasser, ville vi ganske enkelt definere et grensesnitt og få klassene til å implementere dette grensesnittet. I kontrollerne, den viktigste belastningen på metodene skyldes ikke metodens signaturer, men på grunn av metodekommentarene.

Våren 5.1 introduserte imidlertid en ny funksjon:

Kontrollantparameterkommentarer blir også oppdaget på grensesnitt: Tillater fullstendige kartleggingskontrakter i kontrollergrensesnitt.

La oss undersøke hvordan vi kan bruke denne funksjonen.

3. Kontrollerens grensesnitt

3.1. Kontekstoppsett

Vi illustrerer den nye funksjonen ved å bruke et eksempel på et veldig enkelt REST-program som administrerer bøker. Den vil bestå av bare en kontroller med metoder som lar oss hente og endre bøkene.

I opplæringen konsentrerer vi oss bare om problemene knyttet til funksjonen. Alle implementeringsproblemer i applikasjonen finner du i GitHub-arkivet.

3.2. Grensesnitt

La oss definere et vanlig Java-grensesnitt der vi ikke bare definerer signaturene til metodene, men også typen nettforespørsler de skal håndtere:

@RequestMapping ("/ default") offentlig grensesnitt BookOperations {@GetMapping ("/") List getAll (); @GetMapping ("/ {id}") Valgfritt getById (@PathVariable int id); @PostMapping ("/ save / {id}") public void save (@RequestBody Book book, @PathVariable int id); }

Legg merke til at vi kan ha en merknad på klassenivå i tillegg til metodenivå. Nå kan vi lage en kontroller som implementerer dette grensesnittet:

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

Vi bør fortsatt legge til merknad på klassenivå @RestController eller @Kontrollør til kontrolleren vår. Definert på denne måten arver kontrolleren alle merknader relatert til kartleggingen av nettforespørslene.

For å kontrollere at kontrolleren nå fungerer som forventet, la oss kjøre applikasjonen og trykke på få alt() metode ved å gjøre den tilsvarende forespørselen:

krøll // localhost: 8081 / bok /

Selv om kontrolleren implementerer grensesnittet, kan vi finjustere det ytterligere ved å legge til kommentarer om webforespørsel. Vi kan gjøre det på en måte som vi gjorde for grensesnittet: enten på klassenivå eller på metodenivå. Vi har faktisk brukt denne muligheten når vi definerer kontrolleren:

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

Hvis vi legger til merknader om nettforespørsel til kontrolleren, har de forrang for grensesnittets. Med andre ord, Spring tolker kontrolleren grensesnitt på en måte som ligner på hvordan Java håndterer arv.

Vi definerer alle vanlige egenskaper for nettforespørsel i grensesnittet, men i kontrolleren kan vi alltid finjustere dem.

3.3. Forsiktig Merknad

Når vi har et grensesnitt og ulike kontrollere som implementerer det, kan det hende vi ender i en situasjon der en nettforespørsel kan håndteres av mer enn én metode. Naturligvis vil våren kaste et unntak:

Forårsaket av: java.lang.IllegalStateException: Tvetydig kartlegging.

Hvis vi pynter kontrolleren med @RequestMapping, kan vi redusere risikoen for tvetydige kartlegginger.

4. Konklusjon

I denne opplæringen har vi vurdert en ny funksjon introdusert våren 5.1. Når Spring MVC-kontrollere implementerer et grensesnitt, gjør de dette ikke bare på vanlig Java-måte, men arver også all funksjonalitet knyttet til nettforespørsel definert i grensesnittet.

Som alltid kan vi finne de tilsvarende kodebitene på GitHub-depotet vårt.