streamalism.org

1. Oversikt

Vår 4.3. introduserte noen veldig kule komponerte merknader på metodenivå for å jevne ut håndteringen @RequestMapping i typiske Spring MVC-prosjekter.

I denne artikkelen vil vi lære hvordan du bruker dem på en effektiv måte.

2. Nye merknader

Vanligvis hvis vi ønsker å implementere URL-behandleren ved hjelp av tradisjonell @RequestMapping kommentar, det ville ha vært noe sånt:

@RequestMapping (verdi = "/ get / {id}", metode = RequestMethod.GET)

Den nye tilnærmingen gjør det mulig å forkorte dette ganske enkelt til:

@GetMapping ("/ get / {id}")

Spring støtter for tiden fem typer innebygde merknader for å håndtere forskjellige typer innkommende HTTP-forespørselsmetoder som er FÅ, POST, PUT, SLETT og LAPP. Disse kommentarene er:

• @GetMapping
• @PostMapping
• @PutMapping
• @DeleteMapping
• @PatchMapping

Fra navnekonvensjonen kan vi se at hver kommentar er ment å håndtere respektive innkommende forespørselmetodetype, dvs. @GetMapping brukes til å håndtere FÅ type forespørselsmetode, @PostMapping brukes til å håndtere POST type forespørselsmetode osv.

3. Hvordan det fungerer

Alle kommentarene ovenfor er allerede kommentert internt med @RequestMapping og den respektive verdien i metode element.

For eksempel hvis vi ser på kildekoden til @GetMapping kommentar, kan vi se at den allerede er kommentert med RequestMethod.GET på følgende måte:

@Target ({java.lang.annotation.ElementType.METHOD}) @Retention (RetentionPolicy.RUNTIME) @Documented @RequestMapping (method = {RequestMethod.GET}) public @interface GetMapping {// abstrakte koder}

Alle de andre kommentarene er opprettet på samme måte, dvs. @PostMapping er kommentert med RequestMethod.POST, @PutMapping er kommentert med RequestMethod.PUT, etc.

Den fullstendige kildekoden til merknadene er tilgjengelig her.

4. Gjennomføring

La oss prøve å bruke disse kommentarene til å bygge en rask REST-applikasjon.

Vær oppmerksom på at siden vi bruker Maven til å bygge prosjektet og Spring MVC for å lage vår applikasjon, må vi legge til nødvendige avhengigheter i pom.xml:

 org.springframework spring-webmvc 5.2.2.RELEASE 

Den siste versjonen av vår-webmvc er tilgjengelig i Central Maven Repository.

Nå må vi opprette kontrolleren for å tilordne URL for innkommende forespørsel. Inne i denne kontrolleren vil vi bruke alle disse kommentarene en etter en.

4.1. @GetMapping

@GetMapping ("/ get") offentlig @ResponseBody ResponseEntity get () {return new ResponseEntity ("GET Response", HttpStatus.OK); } 

@GetMapping ("/ get / {id}") public @ResponseBody ResponseEntity getById (@PathVariable String id) {return new ResponseEntity ("GET Response:" + id, HttpStatus.OK); }

4.2. @PostMapping

@PostMapping ("/ post") public @ResponseBody ResponseEntity post () {return new ResponseEntity ("POST Response", HttpStatus.OK); }

4.3. @PutMapping

@PutMapping ("/ put") public @ResponseBody ResponseEntity put () {return new ResponseEntity ("PUT Response", HttpStatus.OK); }

4.4. @DeleteMapping

@DeleteMapping ("/ delete") public @ResponseBody ResponseEntity delete () {return new ResponseEntity ("DELETE Response", HttpStatus.OK); }

4.5. @PatchMapping

@PatchMapping ("/ patch") offentlig @ResponseBody ResponseEntity patch () {return new ResponseEntity ("PATCH Response", HttpStatus.OK); }

Poeng å merke seg:

• Vi har brukt de nødvendige kommentarene for å håndtere riktige innkommende HTTP-metoder med URI. For eksempel, @GetMapping å håndtere “/ få” URI, @PostMapping å håndtere “/ post” URI og så videre

• Siden vi lager et REST-basert program, returnerer vi en konstant streng (unik for hver forespørselstype) med 200 responskode for å forenkle applikasjonen. Vi har brukt vårens @ResponseBody kommentar i dette tilfellet.
• Hvis vi måtte håndtere en URL-variabel, kan vi ganske enkelt gjøre det på mye mindre måte vi pleide å gjøre i tilfelle vi brukte det @RequestMapping.

5. Testing av applikasjonen

For å teste applikasjonen må vi opprette et par testsaker ved hjelp av JUnit. Vi ville brukt SpringJUnit4ClassRunner å starte testklassen. Vi ville lage fem forskjellige testtilfeller for å teste hver kommentar og hver behandler vi erklærte i kontrolleren.

La oss enkelt eksemplet test tilfelle av @GetMapping:

@Test public void giventUrl_whenGetRequest_thenFindGetResponse () kaster unntak {MockHttpServletRequestBuilder builder = MockMvcRequestBuilders .get ("/ get"); ResultMatcher contentMatcher = MockMvcResultMatchers.content () .streng ("GET Response"); this.mockMvc.perform (builder) .andExpect (contentMatcher) .andExpect (MockMvcResultMatchers.status (). isOk ()); }

Som vi ser, forventer vi en konstant streng “FÅ svar“, Når vi først traff FÅ URL “/ get”.

La oss nå lage testsaken for å teste @PostMapping:

@Test offentlig ugyldig givenUrl_whenPostRequest_thenFindPostResponse () kaster unntak {MockHttpServletRequestBuilder builder = MockMvcRequestBuilders .post ("/ post"); ResultMatcher contentMatcher = MockMvcResultMatchers.content () .streng ("POST-svar"); this.mockMvc.perform (builder) .andExpect (contentMatcher) .andExpect (MockMvcResultMatchers.status (). isOk ()); }

På samme måte opprettet vi resten av testtilfellene for å teste alle HTTP-metodene.

Alternativt kan vi alltid bruke en hvilken som helst vanlig REST-klient, for eksempel PostMan, RESTClient etc, for å teste applikasjonen vår. I så fall må vi være litt forsiktige med å velge riktig HTTP-metodetype mens vi bruker resten-klienten. Ellers ville det kaste 405 feilstatus.

6. Konklusjon

I denne artikkelen hadde vi en rask introduksjon til de forskjellige typene @RequestMapping snarveier for rask webutvikling ved bruk av tradisjonelle Spring MVC-rammeverk. Vi kan bruke disse raske snarveiene til å skape en ren kodebase.

Som alltid kan du finne kildekoden for denne opplæringen i Github-prosjektet.