streamalism.org

1. Oversigt

Routing er et almindeligt koncept, der vises i de fleste webudviklingsrammer, herunder Spring MVC.

En rute er et URL-mønster, der kortlægges til en handler. Handleren kan være en fysisk fil, såsom et aktiv, der kan downloades, i webapplikationen eller en klasse, der behandler anmodningen, såsom en controller i en MVC-applikation.

I denne vejledning undersøger vi aspektet af routing i udvikling af webapplikationer med Play Framework.

2. Opsætning

Først skal vi oprette et Java Play-program. Detaljerne om, hvordan du konfigurerer Play Framework på en maskine, findes i vores indledende artikel.

Ved afslutningen af ​​installationen skal vi have et fungerende Play-program, som vi kan få adgang til fra en browser.

3. HTTP-routing

Så hvordan ved Play, hvilken controller der skal konsulteres, når vi sender en HTTP-anmodning? Svaret på dette spørgsmål ligger i app / conf / ruter konfigurationsfil.

Play's router oversætter HTTP-anmodninger til handlingsopkald. HTTP-anmodninger betragtes som begivenheder i MVC-arkitektur og routeren reagerer på dem ved at konsultere ruter fil, for hvilken controller og hvilken handling i den controller, der skal udføres.

Hver af disse begivenheder leverer en router med to parametre: en anmodningssti med dens forespørgselsstreng og anmodningens HTTP-metode.

4. Grundlæggende routing med leg

For at routeren skal udføre sit arbejde, er conf / ruter filen skal definere tilknytninger af HTTP-metoder og URI-mønstre til passende controllerhandlinger:

GET / controllers.HomeController.index GET / assets / * fil controllers.Assets.versioned (sti = "/ offentlig", fil: Aktiv)

Alle rutefiler skal også kortlægge de statiske ressourcer i play-routing / offentlig mappe tilgængelig for klienten på / aktiver slutpunkt.

Bemærk syntaksen for at definere HTTP-ruter og HTTP-metoden plads URI mønster plads controller handling.

5. URI-mønstre

I dette afsnit vil vi forklare lidt om URI-mønstre.

5.1. Statiske URI-mønstre

De første tre URI-mønstre ovenfor er statiske. Dette betyder, at kortlægning af URL'erne til ressourcer sker uden yderligere behandling i controllerhandlingerne.

Så længe der kaldes en controller-metode, returnerer den en statisk ressource, hvis indhold bestemmes før anmodningen.

5.2. Dynamiske URI-mønstre

Det sidste URI-mønster ovenfor er dynamisk. Dette betyder, at den controllerhandling, der betjener en anmodning om disse URI'er, har brug for nogle oplysninger fra anmodningen for at bestemme svaret. I ovennævnte tilfælde forventer det et filnavn.

Den normale rækkefølge af begivenheder er, at routeren modtager en begivenhed, vælger stien fra URL'en, afkoder dens segmenter og sender dem til controlleren.

Sti- og forespørgselsparametre injiceres derefter i controller-handlingen som parametre. Vi demonstrerer dette med et eksempel i de næste sektioner.

6. Avanceret routing med leg

I dette afsnit vil vi diskutere avancerede muligheder for routing ved hjælp af dynamiske URI-mønstre i detaljer.

6.1. Enkle sti-parametre

Enkle stiparametre er ikke navngivne parametre i en anmodnings-URL, der vises efter værten og porten og parses i rækkefølge efter udseende.

Inde play-routing / app / HomeController.java, lad os oprette en ny handling:

offentlig resultathilsen (strengnavn) {return ok ("Hej" + navn); }

Vi vil være i stand til at vælge en styparameter fra anmodnings-URL'en og kortlægge den til variabelnavnet.

Routeren får disse værdier fra en rutekonfiguration.

Så lad os åbne play-routing / conf / ruter og opret en kortlægning for denne nye handling:

GET / greet /: name controllers.HomeController.greet (navn: String)

Læg mærke til, hvordan vi informerer en router om, at navnet er et dynamisk stisegment med kolon-syntaksen og derefter fortsætter med at videregive det som en parameter til hilsen-handling-opkaldet.

Lad os nu indlæse // locahost: 9000 / greet / john i browseren, og vi bliver mødt med navn:

Hej John

Det sker således, at hvis vores handlingsparameter er af strengtype, kan vi sende den under handlingsopkaldet uden at specificere parametertypen, selvom dette ikke er det samme for andre typer.

Lad os krydre vores /hilse slutpunkt med aldersoplysninger.

Tilbage til HomeController'S hilsen handling, vi ændrer det til:

offentlig resultathilsen (strengnavn, int-alder) {return ok ("Hej" + navn + ", du er" + alder + "år gammel"); }

Og ruten til:

GET / greet /: name /: age controllers.HomeController.greet (navn: String, age: Integer)

Bemærk også Scala-syntaksen for at erklære en variabel, alder: heltal. I Java bruger vi Heltalder syntaks. Play Framework er bygget i Scala. Derfor er der en masse scala-syntaks.

Lad os indlæse // localhost: 9000 / hilsen / john / 26:

Hej john, du er 26 år gammel

6.2. Jokertegn i stiparametre

I vores rutekonfigurationsfil er den sidste kortlægning:

GET / assets / * file controllers.Assets.versioned (sti = "/ offentlig", fil: Aktiv)

Vi bruger et jokertegn i den dynamiske del af stien. Hvad vi fortæller Play er, at uanset hvilken værdi der erstatter *fil i den faktiske anmodning skal parses som en helhed og ikke afkodes som i andre tilfælde af styparametre.

I dette eksempel er controlleren en indbygget, Aktiver, som gør det muligt for klienten at downloade filer fra play-routing / offentlig folder. Når vi indlæser //localhost:9000/assets/images/favicon.png, skal vi se billedet af Play favicon i browseren, da det er til stede i / offentligt / billeder folder.

Lad os oprette vores eget eksempel i HomeController.java:

offentligt resultat introducMe (String data) {String [] clientData = data.split (","); returner ok ("Dit navn er" + clientData [0] + ", du er" + clientData [1] + "år gammel"); }

Bemærk, at vi i denne handling modtager en strengparameter og anvender vores logik til at afkode den. I dette tilfælde er logikken at opdele et komma-afgrænset Snor ind i en matrix. Tidligere var vi afhængige af en router for at afkode disse data for os.

Med jokertegn er vi alene. Vi håber, at klienten får vores syntaks korrekte, når de sender disse data. Ideelt set vi skal validere den indgående streng, før vi bruger den.

Lad os oprette en rute til denne handling:

GET / * data controllere.HomeController.introduceMe (data)

Indlæs nu URL'en // localhost: 9000 / john, 26. Dette vil udskrive:

Dit navn er john, du er 26 år gammel

6.3. Regex i stiparametre

Ligesom jokertegn kan vi bruge regulære udtryk til den dynamiske del. Lad os tilføje en handling, der modtager et tal og returnerer dets firkant:

offentligt resultat squareMe (Langt antal) {returnere ok (num + "Squared er" + (num * num)); }

Nu tilføjer vi sin rute:

GET / firkant / $ num-controllere.HomeController.squareMe (num: Lang)

Lad os placere denne rute under introducer mig rute for at introducere et nyt koncept. Vi kan kun håndtere ruter, hvor regex-delen er et positivt heltal med denne routingkonfiguration.

Nu hvis vi har placeret ruten som beskrevet i foregående afsnit, og vi indlæser // localhost: 9000 / kvadrat / 2, skal vi blive mødt med en ArrayIndexOutOfBoundsException:

Hvis vi tjekker fejllogfilerne i serverkonsollen, vil vi indse, at handlingsopkaldet faktisk blev udført den introducer mig handling snarere end firkantet mig handling. Som tidligere nævnt om jokertegn er vi alene og validerede ikke indgående data.

I stedet for en komma-afgrænset streng, er introducer mig metode blev kaldt med strengen “firkant / 2“. Derfor, efter at have delt det, fik vi en række af størrelse 1. Forsøger at nå indeks 1 kastede derefter undtagelsen.

Naturligvis forventer vi, at opkaldet sendes til firkantet mig metode. Hvorfor blev det sendt til introducer mig? Årsagen er en Play-funktion, vi dækker næste kaldte Ruteprioritet.

7. Ruteprioritet

Hvis der er en konflikt mellem ruter, som der er mellem firkantet mig og introducer mig, derefter Play vælger den første rute i deklarationsrækkefølge.

Hvorfor er der en konflikt? På grund af stien til jokertegn /*data matcher enhver anmodnings-URL bortset fra basisstien /. Så hver rute, hvis URI-mønster bruger jokertegn, skal vises sidst i rækkefølge.

Lad os nu ændre deklarationsrækkefølgen for ruterne, således at introducer mig ruten kommer efter firkantet mig og genindlæs:

2 i firkant er 4

For at teste styrken af ​​regulære udtryk i en rute, prøv at indlæse // locahost: 9000 / kvadrat / -1, kan en router ikke matche firkantet mig rute. I stedet vil det matche introducere mig, og vi får den ArrayIndexOutOfBoundsException igen.

Dette er fordi -1 stemmer ikke overens med det angivne regulære udtryk, heller ikke nogen alfabetisk karakter.

8. Parametre

Indtil dette punkt har vi dækket syntaksen til erklæring af parametertyper i rutefilen.

I dette afsnit ser vi på flere tilgængelige muligheder, når vi beskæftiger os med parametre i ruter.

8.1. Parametre med faste værdier

Nogle gange vil vi gerne bruge en fast værdi til en parameter. Dette er vores måde at fortælle Play om at bruge den angivne styparameter, eller hvis anmodningskonteksten er stien /, brug derefter en bestemt fast værdi.

En anden måde at se på det er at have to slutpunkter eller kontekststier, der fører til den samme controllerhandling - med det ene slutpunkt, der kræver en parameter fra anmodnings-URL'en, og standardindstillingen til den anden, hvis den nævnte parameter er fraværende.

Lad os tilføje en for at demonstrere dette forfatter() handling til HomeController:

offentlig resultatforfatter () {return ok ("Routing in Play by Baeldung"); }

Forudsat at vi ikke altid vil have vores API til at returnere en Snor:

Routing in Play af Baeldung

Vi ønsker at kontrollere det ved at sende navnet på en forfatter af artiklen sammen med anmodningen, som standard til den faste værdi Baeldung kun hvis anmodningen ikke har forfatter parameter.

Så lad os ændre yderligere forfatter handling ved at tilføje en parameter:

offentlig resultatforfatter (strengforfatter) {return ok ("REST API med afspilning af" + forfatter); }

Lad os også se, hvordan du tilføjer en parameter med fast værdi til ruten:

GET / writer controllers.HomeController.writer (author = "Baeldung") GET / writer /: author controllers.HomeController.writer (author: String)

Læg mærke til, hvordan vi nu har to separate ruter, der alle fører til HomeController.index handling i stedet for en.

Når vi nu indlæser // localhost: 9000 / forfatter fra browseren får vi:

Routing in Play af Baeldung

Og når vi indlæser // localhost: 9000 / skribent / john, vi får:

Routing in Play af john

8.2. Parametre med standardværdier

Bortset fra at have faste værdier, kan parametre også have standardværdier. Begge giver reserveværdier til controllerens handlingsparametre, hvis anmodningen ikke indeholder de krævede værdier.

Forskellen mellem de to er, at faste værdier bruges som et tilbagefald for styparametre, mens standardværdier bruges som en tilbageførsel til forespørgselsparametre.

Stiparametre er af formularen // localhost: 9000 / param1 / param2 og forespørgselsparametre er af formularen // localhost: 9000 /? param1 = værdi1¶m2 = værdi2.

Den anden forskel er i syntaksen for at erklære de to i en rute. Parametre med fast værdi bruger tildelingsoperatøren som i:

author = "Baeldung"

Mens standardværdier bruger en anden type tildeling:

forfatter? = "Baeldung"

Vi bruger ?= operatør, som betinget tildeler Baeldung til forfatter i tilfælde af forfatter viser sig at indeholde ingen værdi.

For at få en komplet demonstration, lad os oprette HomeController.writer handling. Lad os sige, bortset fra forfatterens navn, som er en stiparameter, vil vi også videregive forfatteren id som en forespørgselsparameter, som skal være standard til 1 hvis ikke godkendt i anmodningen.

Vi ændrer os forfatter handling til:

offentlig resultatforfatter (strengforfatter, int-id) {return ok ("Routing in Play by:" + author + "ID:" + id); }

og forfatter ruter til:

GET / writer controllers.HomeController.writer (author = "Baeldung", id: Int? = 1) GET / writer /: author controllers.HomeController.writer (author: String, id: Int? = 1)

Indlæser nu // localhost: 9000 / forfatter vi ser:

Routing in Play af: Baeldung ID: 1

At ramme // localhost: 9000 / skribent? id = 10 giver os:

Routing in Play af: Baeldung ID: 10

Hvad med // localhost: 9000 / skribent / john?

Routing in Play af: john ID: 1

Og endelig, // localhost: 9000 / skribent / john? id = 5 vender tilbage:

Routing in Play af: john ID: 5

9. Konklusion

I denne artikel undersøgte vi begrebet Routing i Play-applikationer. Vi har også en artikel om at opbygge en RESTful API med Play Framework, hvor routingskoncepterne i denne vejledning anvendes i et praktisk eksempel.

Som normalt er kildekoden til denne vejledning tilgængelig på GitHub.