Spring RequestMapping

1. Oversigt

I denne vejledning fokuserer vi på en af ​​de vigtigste kommentarer i Forår MVC: @RequestMapping.

Kort sagt bruges kommentaren til at kortlægge webanmodninger til Spring Controller-metoder.

2. @RequestMapping Grundlæggende

Lad os starte med et simpelt eksempel: kortlægge en HTTP-anmodning til en metode ved hjælp af nogle grundlæggende kriterier.

2.1. @RequestMapping - ved sti

@RequestMapping (værdi = "/ ex / foos", metode = RequestMethod.GET) @ResponseBody offentlig String getFoosBySimplePath () {return "Get some Foos"; }

At teste denne kortlægning med en simpel krølle kommando, kør:

curl -i // localhost: 8080 / spring-rest / ex / foos

2.2. @RequestMapping - HTTP-metoden

HTTP metode parameter har ingen standard. Så hvis vi ikke angiver en værdi, kortlægges den til enhver HTTP-anmodning.

Her er et simpelt eksempel svarende til det forrige, men denne gang kortlagt til en HTTP POST-anmodning:

@RequestMapping (værdi = "/ ex / foos", metode = POST) @ResponseBody offentlig String postFoos () {return "Send nogle Foos"; }

For at teste POST via a krølle kommando:

krølle -i -X ​​POST // localhost: 8080 / spring-rest / ex / foos

3. RequestMapping og HTTP-overskrifter

3.1. @RequestMapping Med overskrifter Attribut

Kortlægningen kan indsnævres yderligere ved at angive en overskrift til anmodningen:

@RequestMapping (value = "/ ex / foos", headers = "key = val", method = GET) @ResponseBody public String getFoosWithHeader () {return "Get some Foos with Header"; }

For at teste operationen skal vi bruge krølle header support:

curl -i -H "key: val" // localhost: 8080 / spring-rest / ex / foos

og endda flere overskrifter via overskrifter attribut for @RequestMapping:

@RequestMapping (value = "/ ex / foos", headers = {"key1 = val1", "key2 = val2"}, method = GET) @ResponseBody public String getFoosWithHeaders () {return "Få nogle foos med header"; }

Vi kan teste dette med kommandoen:

krølle -i -H "key1: val1" -H "key2: val2" // localhost: 8080 / spring-rest / ex / foos

Bemærk, at for krølle syntaks, et kolon adskiller header-nøglen og header-værdien, det samme som i HTTP-specifikationen, mens der i foråret bruges ligetegn.

3.2. @RequestMapping Forbruger og producerer

Kortlægning medietyper produceret af en controller metode er særlig opmærksom.

Vi kan kortlægge en anmodning baseret på dens Acceptere header via @RequestMappingoverskrifter attribut introduceret ovenfor:

@RequestMapping (værdi = "/ ex / foos", metode = GET, overskrifter = "Accepter = applikation / json") @ResponseBody offentlig String getFoosAsJsonFromBrowser () {return "Få nogle Foos med Header Old"; }

Matchningen til denne måde at definere Acceptere header er fleksibel - den bruger indeholder i stedet for lig med, så en anmodning som følgende vil stadig kortlægges korrekt:

krølle -H "Accepter: applikation / json, tekst / html" // localhost: 8080 / spring-rest / ex / foos

Startende med forår 3.1, den @RequestMapping annotering har nu producerer og forbruger egenskaber, specifikt til dette formål:

@RequestMapping (værdi = "/ ex / foos", metode = RequestMethod.GET, producerer = "applikation / json") @ResponseBody offentlig String getFoosAsJsonFromREST () {return "Få nogle Foos med Header New"; }

Også den gamle type kortlægning med overskrifter attribut konverteres automatisk til det nye producerer mekanisme startende med Spring 3.1, så resultaterne bliver identiske.

Dette forbruges via krølle på samme måde:

krølle -H "Accepter: applikation / json" // localhost: 8080 / spring-rest / ex / foos

Derudover producerer understøtter også flere værdier:

@RequestMapping (værdi = "/ ex / foos", metode = GET, producerer = {"applikation / json", "applikation / xml"})

Husk, at disse - de gamle og nye måder at specificere Acceptere header - er dybest set den samme kortlægning, så Spring tillader dem ikke sammen.

At have begge disse metoder aktive ville resultere i:

Forårsaget af: java.lang.IllegalStateException: flertydig kortlægning fundet. Kan ikke kortlægge 'fooController' bønnemetoden java.lang.String org.baeldung.spring.web.controller .FooController.getFoosAsJsonFromREST () til {[/ ex / foos], methods = [GET], params = [], headers = [ ], forbruger = [], producerer = [applikation / json], brugerdefineret [[}}: Der er allerede 'fooController' bønnemetode java.lang.String org.baeldung.spring.web.controller .FooController.getFoosAsJsonFromBrowser () kortlagt .

En sidste note om det nye producerer og forbruger mekanismer, der opfører sig forskelligt fra de fleste andre kommentarer: Når det specificeres på typeniveau, annoteringer på metodeniveau supplerer ikke, men tilsidesætter oplysningerne på typeniveau.

Og selvfølgelig, hvis du vil grave dybere ned i at opbygge en REST API med Spring, skal du tjekke ud den nye REST med forårskursus.

4. RequestMapping Med stivariabler

Dele af kortlægnings-URI kan bindes til variabler via @PathVariable kommentar.

4.1. Enkelt @PathVariable

Et simpelt eksempel med en enkelt sti-variabel:

@RequestMapping (værdi = "/ ex / foos / {id}", metode = GET) @ResponseBody offentlig streng getFoosBySimplePathWithPathVariable (@PathVariable ("id") lang id) {return "Få en specifik Foo med / ex / foos / { id} ", method = GET) @ResponseBody public String getFoosBySimplePathWithPathVariable (@PathVariable String id) {return" Få en bestemt Foo med2-multiple-pathvariable ">4.2. Mange @PathVariable

En mere kompleks URI skal muligvis kortlægge flere dele af URI til flere værdier:

@RequestMapping (value = "/ ex / foos / {fooid} / bar / {barid}", method = GET) @ResponseBody public String getFoosBySimplePathWithPathVariables (@PathVariable long fooid, @PathVariable long barid) {return "Få en specifik bar med fra en Foo med3-pathvariable-med-regex ">4.3. @PathVariable Med Regex

Regulære udtryk kan også bruges ved kortlægning af @PathVariable.

For eksempel begrænser vi kortlægningen til kun at acceptere numeriske værdier for id:

@RequestMapping (værdi = "/ ex / søjler / {numericId: [\ d] +}", metode = GET) @ResponseBody offentlig String getBarsBySimplePathWithPathVariable (@PathVariable long numericId) {return "Få en specifik søjle med forespørgsel-param">5. RequestMapping Med anmodningsparametre

@RequestMapping tillader let kortlægning af URL-parametre med @RequestParam kommentar.

Vi kortlægger nu en anmodning til en URI:

// localhost: 8080 / spring-rest / ex / bars? id = 100
@RequestMapping (værdi = "/ ex / søjler", metode = GET) @ResponseBody offentlig String getBarBySimplePathWithRequestParam (@RequestParam ("id") lang id) {return "Få en bestemt søjle med / ex / søjler", params = "id ", method = GET) @ResponseBody public String getBarBySimplePathWithExplicitRequestParam (@RequestParam (" id ") lang id) {return" Få en bestemt bjælke med / ex / søjler ", params = {" id "," second "}, method = GET) @ResponseBody public String getBarBySimplePathWithExplicitRequestParams (@RequestParam ("id") lang id) {return "Narrow Få en bestemt søjle medcorner-cases">6. RequestMapping Hjørnesager

6.1. @RequestMapping - Flere stier kortlagt til den samme controller-metode

Selvom en enkelt @RequestMapping sti værdi bruges normalt til en enkelt controller metode (bare god praksis, ikke en hård og hurtig regel), der er nogle tilfælde, hvor det kan være nødvendigt at kortlægge flere anmodninger til den samme metode.

I det tilfælde, det værdi attribut for @RequestMapping accepterer flere tilknytninger, ikke kun en enkelt:

@RequestMapping (værdi = {"/ ex / avanceret / søjler", "/ ex / avanceret / foos"}, metode = GET) @ResponseBody offentlig String getFoosOrBarsByPath () {return "Avanceret - Få nogle Foos eller Bars"; }

Nu begge disse krølle kommandoer skal ramme samme metode:

curl -i // localhost: 8080 / spring-rest / ex / advanced / foos curl -i // localhost: 8080 / spring-rest / ex / advanced / bars

6.2. @RequestMapping - Flere HTTP-anmodningsmetoder til den samme controller-metode

Flere anmodninger ved hjælp af forskellige HTTP-verb kan tilknyttes den samme controller-metode:

@RequestMapping (værdi = "/ ex / foos / multiple", metode = {RequestMethod.PUT, RequestMethod.POST}) @ResponseBody offentlig String putAndPostFoos () {return "Avanceret - PUT og POST inden for en enkelt metode"; }

Med krølle, begge disse vil nu ramme den samme metode:

krølle -i -X ​​POST // localhost: 8080 / spring-rest / ex / foos / multiple curl -i -X ​​PUT // localhost: 8080 / spring-rest / ex / foos / multiple

6.3. @RequestMapping - et tilbagefald for alle anmodninger

Sådan implementeres et simpelt fallback for alle anmodninger ved hjælp af en bestemt HTTP-metode, for eksempel for en GET:

@RequestMapping (værdi = "*", metode = RequestMethod.GET) @ResponseBody offentlig String getFallback () {return "Fallback for GET Requests"; }

eller endda for alle anmodninger:

@RequestMapping (værdi = "*", metode = {RequestMethod.GET, RequestMethod.POST ...}) @ResponseBody public String allFallback () {return "Fallback for All Requests"; }

6.4. Tvetydig kortlægningsfejl

Den tvetydige kortlægningsfejl opstår, når Spring vurderer to eller flere anmodningstilknytninger for at være de samme for forskellige controller-metoder. En anmodningstilknytning er den samme, når den har den samme HTTP-metode, URL, parametre, overskrifter og medietype.

For eksempel er dette en tvetydig kortlægning:

@GetMapping (værdi = "foos / duplikat") offentlig streng duplikat () {returner "duplikat"; } @GetMapping (værdi = "foos / duplikat") offentlig streng duplikateks () {returner "duplikat"; }

Den undtagelse, der kastes, har normalt fejlmeddelelser i denne retning:

Forårsaget af: java.lang.IllegalStateException: flertydig kortlægning. Kan ikke kortlægge 'fooMappingExamplesController' metode offentlig java.lang.String org.baeldung.web.controller.FooMappingExamplesController.duplicateEx () til {[/ ex / foos / duplicate], metoder = [GET]}: Der er allerede 'fooMappingExamplesController' bønne metode offentlig java.lang.String org.baeldung.web.controller.FooMappingExamplesController.duplicate () kortlagt.

En omhyggelig læsning af fejlmeddelelsen peger på, at Spring ikke er i stand til at kortlægge metoden org.baeldung.web.controller.FooMappingExamplesController.duplicateEx (), da den har en modstridende kortlægning med en allerede kortlagt org.baeldung.web.controller.FooMappingExamplesController.duplicate ().

Kodestykket nedenfor resulterer ikke i tvetydig kortlægningsfejl, fordi begge metoder returnerer forskellige indholdstyper:

@GetMapping (værdi = "foos / duplicate", producerer = MediaType.APPLICATION_XML_VALUE) offentlig String duplicateXml () {return "Duplicate"; } @GetMapping (værdi = "foos / duplicate", producerer = MediaType.APPLICATION_JSON_VALUE) offentlig String duplicateJson () {return "{\" meddelelse \ ": \" Duplicate \ "}"; }

Denne differentiering gør det muligt for vores controller at returnere den korrekte datarepræsentation baseret på Accepterer header leveret i anmodningen.

En anden måde at løse dette på er at opdatere den URL, der er tildelt en af ​​de to involverede metoder.

7. Nye anmodningsmappningsgenveje

Spring Framework 4.3 introducerede et par nye HTTP-kortlægningsannoteringer, alle baseret på @RequestMapping :

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

Disse nye bemærkninger kan forbedre læsbarheden og reducere kodes viden.

Lad os se på disse nye kommentarer i aktion ved at oprette en RESTful API, der understøtter CRUD-operationer:

@GetMapping ("/ {id}") offentlig ResponseEntity getBazz (@PathVariable String id) {returner ny ResponseEntity (ny Bazz (id, "Bazz" + id), HttpStatus.OK); } @PostMapping public ResponseEntity newBazz (@RequestParam ("name") String name) {return new ResponseEntity (new Bazz ("5", name), HttpStatus.OK); } @PutMapping ("/ {id}") offentlig ResponseEntity updateBazz (@PathVariable String id, @RequestParam ("name") String name) {return new ResponseEntity (new Bazz (id, name), HttpStatus.OK); } @DeleteMapping ("/ {id}") offentlig ResponseEntity deleteBazz (@PathVariable String id) {returner ny ResponseEntity (ny Bazz (id), HttpStatus.OK); }

Et dybt dyk i disse kan findes her.

8. Forårskonfiguration

Spring MVC-konfigurationen er enkel nok, i betragtning af at vores FooController er defineret i følgende pakke:

pakke org.baeldung.spring.web.controller; @Controller offentlig klasse FooController {...}

Vi har simpelthen brug for en @Konfiguration klasse for at aktivere fuld MVC-understøttelse og konfigurere classpath-scanning til controlleren:

@Configuration @EnableWebMvc @ComponentScan ({"org.baeldung.spring.web.controller"}) offentlig klasse MvcConfig {//}

9. Konklusion

Denne artikel fokuserede på @RequestMapping kommentar om foråret, diskuterer en simpel brugssag, kortlægning af HTTP-overskrifter, bindende dele af URI med @PathVariableog arbejde med URI-parametre og @RequestParam kommentar.

Hvis du gerne vil lære, hvordan du bruger en anden kernebemærkning i Spring MVC, kan du udforske @ModelAttribute kommentar her.

Den fulde kode fra artiklen er tilgængelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found