streamalism.org

1. Oversigt

Forår 4.3. introducerede nogle meget seje sammensatte annoteringer på metodeniveau for at udglatte håndteringen @RequestMapping i typiske forårsmVC-projekter.

I denne artikel vil vi lære at bruge dem på en effektiv måde.

2. Nye kommentarer

Typisk, hvis vi vil implementere URL-handleren ved hjælp af traditionel @RequestMapping kommentar, det ville have været noget som dette:

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

Den nye tilgang gør det muligt at forkorte dette blot til:

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

Spring understøtter i øjeblikket fem typer indbyggede annoteringer til håndtering af forskellige typer indgående HTTP-anmodningsmetoder, som er FÅ, POST, SÆT, SLET og LAPPE. Disse kommentarer er:

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

Fra navngivningskonventionen kan vi se, at hver annotering er beregnet til at håndtere de respektive indkommende anmodningmetodetyper, dvs. @GetMapping bruges til at håndtere FÅ type anmodningsmetode @PostMapping bruges til at håndtere STOLPE type anmodningsmetode osv.

3. Sådan fungerer det

Alle ovenstående kommentarer er allerede internt kommenteret med @RequestMapping og den respektive værdi i metode element.

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

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

Alle andre kommentarer oprettes på samme måde, dvs. @PostMapping er kommenteret med RequestMethod.POST, @PutMapping er kommenteret med RequestMethod.PUT, etc.

Kommentarernes fulde kildekode er tilgængelig her.

4. Implementering

Lad os prøve at bruge disse kommentarer til at opbygge en hurtig REST-applikation.

Bemærk, at da vi bruger Maven til at opbygge projektet og Spring MVC til at oprette vores applikation, er vi nødt til at tilføje nødvendige afhængigheder i pom.xml:

 org.springframework spring-webmvc 5.2.2.RELEASE 

Den seneste version af fjeder-webmvc er tilgængelig i Central Maven Repository.

Nu skal vi oprette controlleren for at kortlægge indgående anmodnings-URL. Inde i denne controller ville vi bruge alle disse bemærkninger en efter en.

4.1. @GetMapping

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

@GetMapping ("/ get / {id}") offentlig @ResponseBody ResponseEntity getById (@PathVariable streng-id) {returner 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 ("SLET svar", HttpStatus.OK); }

4.5. @PatchMapping

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

Punkter at bemærke:

• Vi har brugt de nødvendige kommentarer til at håndtere korrekte indkommende HTTP-metoder med URI. For eksempel, @GetMapping at håndtere “/ get” URI, @PostMapping til at håndtere “/ post” URI og så videre

• Da vi laver en REST-baseret applikation, returnerer vi en konstant streng (unik for hver anmodningstype) med 200 svarskode for at forenkle applikationen. Vi har brugt Spring's @ResponseBody kommentar i dette tilfælde.
• Hvis vi skulle håndtere en URL-sti-variabel, kan vi simpelthen gøre det på meget mindre måde, vi plejede at gøre i tilfælde af brug @RequestMapping.

5. Test af applikationen

For at teste applikationen er vi nødt til at oprette et par testsager ved hjælp af JUnit. Vi ville bruge SpringJUnit4ClassRunner at indlede testklassen. Vi oprettede fem forskellige testsager for at teste hver annotering og hver handler, vi erklærede i controlleren.

Lad os simpelt eksemplet test tilfælde af @GetMapping:

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

Som vi kan se, forventer vi en konstant streng “GET-svar”, Når vi først ramte FÅ URL “/ get”.

Lad os nu oprette testsagen til test @PostMapping:

@Test offentlig ugyldighed givenUrl_whenPostRequest_thenFindPostResponse () kaster undtagelse {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åde oprettede vi resten af ​​testsagerne for at teste alle HTTP-metoderne.

Alternativt kan vi altid bruge enhver almindelig REST-klient, for eksempel PostMan, RESTClient osv., Til at teste vores applikation. I så fald skal vi være lidt forsigtige med at vælge den korrekte HTTP-metodetype, mens vi bruger resten-klienten. Ellers ville det kaste 405 fejlstatus.

6. Konklusion

I denne artikel havde vi en hurtig introduktion til de forskellige typer @RequestMapping genveje til hurtig webudvikling ved hjælp af traditionelle Spring MVC-rammer. Vi kan bruge disse hurtige genveje til at skabe en ren kodebase.

Som altid kan du finde kildekoden til denne vejledning i Github-projektet.