streamalism.org

1. Oversikt

Routing er et vanlig konsept som vises i de fleste nettutviklingsrammer, inkludert Spring MVC.

En rute er et URL-mønster som tilordnes en behandler. Behandleren kan være en fysisk fil, for eksempel et nedlastbart aktivum i webapplikasjonen eller en klasse som behandler forespørselen, for eksempel en kontroller i et MVC-program.

I denne opplæringen vil vi utforske aspektet ved ruting i utviklingen av webapplikasjoner med Play Framework.

2. Oppsett

Først må vi lage et Java Play-program. Detaljer om hvordan du setter opp Play Framework på en maskin er tilgjengelig i vår innledende artikkel.

På slutten av oppsettet bør vi ha et fungerende Play-program som vi har tilgang til fra en nettleser.

3. HTTP-ruting

Så hvordan vet Play hvilken kontroller som skal konsulteres når vi sender en HTTP-forespørsel? Svaret på dette spørsmålet ligger i app / conf / ruter konfigurasjonsfil.

Spillets ruter oversetter HTTP-forespørsler til handlingsanrop. HTTP-forespørsler anses å være hendelser i MVC-arkitektur og ruteren reagerer på dem ved å konsultere ruter fil for hvilken kontroller og hvilken handling i den kontrolleren som skal utføres.

Hver av disse hendelsene leverer en ruter med to parametere: en forespørselsbane med spørringsstrengen og forespørselens HTTP-metode.

4. Grunnleggende ruting med spill

For at ruteren skal gjøre jobben sin, conf / ruter filen må definere kartlegginger av HTTP-metoder og URI-mønstre til passende kontrollerhandlinger:

GET / controllers.HomeController.index GET / assets / * file controllers.Assets.versioned (path = "/ public", file: Asset)

Alle rutefiler må også tilordne de statiske ressursene i play-routing / offentlig mappen tilgjengelig for klienten på /eiendeler endepunkt.

Legg merke til syntaksen for å definere HTTP-ruter og HTTP-metoden rom URI mønster rom kontrollerhandling.

5. URI-mønstre

I denne delen vil vi forklare litt om URI-mønstre.

5.1. Statiske URI-mønstre

De tre første URI-mønstrene ovenfor er statiske. Dette betyr at kartlegging av URL-ene til ressursene skjer uten ytterligere behandling i kontrollerhandlingene.

Så lenge en kontrollermetode kalles, returnerer den en statisk ressurs hvis innhold bestemmes før forespørselen.

5.2. Dynamiske URI-mønstre

Det siste URI-mønsteret ovenfor er dynamisk. Dette betyr at kontrollerhandlingen som betjener en forespørsel på disse URI-ene, trenger litt informasjon fra forespørselen for å bestemme svaret. I ovennevnte tilfelle forventer den et filnavn.

Den normale rekkefølgen av hendelser er at ruteren mottar en hendelse, velger banen fra URL-en, dekoder segmentene og sender dem til kontrolleren.

Baneparametere og spørringsparametere blir deretter injisert i kontrollerhandlingen som parametere. Vi vil demonstrere dette med et eksempel i de neste avsnittene.

6. Avansert ruting med spill

I denne delen vil vi diskutere avanserte alternativer for ruting ved hjelp av dynamiske URI-mønstre i detalj.

6.1. Simple Path Parameters

Enkle baneparametere er ikke navngitte parametere i en URL for forespørsel som vises etter verten og porten og blir analysert i rekkefølge etter utseende.

Innsiden play-routing / app / HomeController.java, la oss lage en ny handling:

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

Vi vil være i stand til å velge en styparameter fra forespørselens URL og tilordne den til variabelnavnet.

Ruteren får disse verdiene fra en rutekonfigurasjon.

Så la oss åpne play-routing / conf / ruter og lag en kartlegging for denne nye handlingen:

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

Legg merke til hvordan vi informerer en ruter om at navnet er et dynamisk banesegment med kolon-syntaksen, og deretter fortsetter med å sende det som en parameter til hilsen-samtalen.

La oss laste // locahost: 9000 / greet / john i nettleseren, og vi blir møtt med navn:

Hei john

Det skjer slik at hvis handlingsparameteren er av strengtype, kan vi sende den under handlingsanropet uten å spesifisere parametertypen, selv om dette ikke er det samme for andre typer.

La oss krydre vår /hilse på sluttpunkt med aldersinformasjon.

Tilbake til HomeControllerHilsen, vi endrer den til:

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

Og ruten til:

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

Legg også merke til Scala-syntaksen for å erklære en variabel, alder: Heltall. I Java bruker vi Hele alder syntaks. Play Framework er bygget i Scala. Derfor er det mye skala syntaks.

La oss laste // localhost: 9000 / hilsen / john / 26:

Hei john, du er 26 år gammel

6.2. Jokertegn i baneparametere

I vår rutekonfigurasjonsfil er den siste kartleggingen:

GET / assets / * file controllers.Assets.versioned (path = "/ public", file: Asset)

Vi bruker et jokertegn i den dynamiske delen av stien. Det vi forteller Play er at uansett hvilken verdi som erstatter *fil i selve forespørselen skal den analyseres som en helhet og ikke dekodes som i andre tilfeller av baneparametere.

I dette eksemplet er kontrolleren en innebygd, Eiendeler, som lar klienten laste ned filer fra play-routing / offentlig mappe. Når vi laster //localhost:9000/assets/images/favicon.png, bør vi se bildet av Play favicon i nettleseren siden det er tilstede i / offentlig / bilder mappe.

La oss lage vår egen eksempelhandling i HomeController.java:

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

Legg merke til at i denne handlingen mottar vi én strengparameter og bruker logikken vår for å dekode den. I dette tilfellet er logikken å dele et komma-avgrenset String inn i en matrise. Tidligere var vi avhengige av en ruter for å dekode disse dataene for oss.

Med jokertegn er vi alene. Vi håper at klienten får syntaksen riktig når han sender inn disse dataene. Ideelt sett vi bør validere innkommende streng før du bruker den.

La oss lage en rute til denne handlingen:

GET / * datakontrollere.HomeController.introduceMe (data)

Last nå URL-en // localhost: 9000 / john, 26. Dette vil skrive ut:

Ditt navn er john, du er 26 år gammel

6.3. Regex i baneparametere

Akkurat som jokertegn, kan vi bruke vanlige uttrykk for den dynamiske delen. La oss legge til en handling som mottar et tall og returnerer kvadratet:

public Result squareMe (Long num) {return ok (num + "Squared is" + (num * num)); }

Nå legger vi til ruten:

GET / kvadrat / $ num-kontrollere.HomeController.squareMe (num: Lang)

La oss plassere denne ruten under Introduser meg rute for å introdusere et nytt konsept. Vi kan bare håndtere ruter der regex-delen er et positivt heltall med denne rutingskonfigurasjonen.

Nå hvis vi har plassert ruten som beskrevet i forrige avsnitt, og vi laster // localhost: 9000 / kvadrat / 2, bør vi bli møtt med en ArrayIndexOutOfBoundsException:

Hvis vi sjekker feilloggene i serverkonsollen, vil vi innse at handlingsanropet faktisk ble utført på Introduser meg handling i stedet for kvadratMe handling. Som sagt tidligere om jokertegn, er vi alene og validerte ikke innkommende data.

I stedet for en kommaavgrenset streng, blir Introduser meg metoden ble kalt med strengen “kvadrat / 2“. Derfor, etter å ha delt den, fikk vi en rekke størrelser en. Prøver å nå indeksen 1 kastet deretter unntaket.

Naturligvis forventer vi at samtalen blir dirigert til kvadratMe metode. Hvorfor ble det dirigert til Introduser meg? Årsaken er en Play-funksjon som vi dekker neste gang Ruteprioritet.

7. Ruteprioritet

Hvis det er en konflikt mellom rutene som det er mellom kvadratMe og Introduser meg, deretter Play velger den første ruten i erklæringsrekkefølge.

Hvorfor er det en konflikt? På grunn av kontekststien med jokertegn /*data samsvarer med hvilken som helst URL forespørsel bortsett fra basisstien /. Så hver rute hvis URI-mønster bruker jokertegn, skal vises sist i rekkefølge.

La oss nå endre deklarasjonsrekkefølgen for rutene slik at Introduser meg rute kommer etter kvadratMe og last inn på nytt:

2 Squared er 4

For å teste kraften til vanlige uttrykk i en rute, prøv å laste inn // locahost: 9000 / kvadrat / -1, vil en ruter ikke samsvarer med kvadratMe rute. I stedet vil det matche Introduser meg, og vi får tak i ArrayIndexOutOfBoundsException en gang til.

Dette er fordi -1 samsvarer ikke med det oppgitte regulære uttrykket, og heller ikke noe alfabetisk karakter.

8. Parametere

Fram til dette punktet har vi dekket syntaksen for å erklære parametertyper i rutefilen.

I denne delen vil vi se på flere tilgjengelige alternativer når vi arbeider med parametere i ruter.

8.1. Parametere med faste verdier

Noen ganger vil vi bruke en fast verdi for en parameter. Dette er vår måte å fortelle Play om å bruke stiparameteren som er gitt, eller om forespørselens kontekst er banen /, bruk deretter en viss fast verdi.

En annen måte å se på det er å ha to endepunkter eller kontekstbaner som fører til den samme kontrollerhandlingen - med det ene endepunktet som krever en parameter fra forespørsels-URL-en og som standard til den andre i tilfelle nevnte parameter er fraværende.

For å demonstrere dette, la oss legge til en forfatter() handling til HomeController:

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

Forutsatt at vi ikke alltid vil at API-en vår skal returnere en String:

Routing in Play av Baeldung

Vi vil kontrollere det ved å sende navnet på en forfatter av artikkelen sammen med forespørselen, som standard til den faste verdien Baeldung bare hvis forespørselen ikke har forfatter parameter.

Så la oss endre på forfatter handling ved å legge til en parameter:

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

La oss også se hvordan du legger til en parameter for fast verdi til ruten:

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

Legg merke til hvordan vi nå har to separate ruter som alle fører til HomeController.index handling i stedet for en.

Når vi nå laster // localhost: 9000 / skribent fra nettleseren får vi:

Routing in Play av Baeldung

Og når vi laster // localhost: 9000 / skribent / john, vi får:

Routing in Play av john

8.2. Parametere med standardverdier

Bortsett fra å ha faste verdier, kan parametere også ha standardverdier. Begge gir reserveverdier til kontrollerens handlingsparametere i tilfelle forespørselen ikke gir de nødvendige verdiene.

Forskjellen mellom de to er at faste verdier brukes som en reserve for baneparametere mens standardverdier brukes som en reserve for spørringsparametere.

Baneparametere er av skjemaet // localhost: 9000 / param1 / param2 og spørringsparametere er av skjemaet // localhost: 9000 /? param1 = verdi1¶m2 = verdi2.

Den andre forskjellen er i syntaksen for å erklære de to i en rute. Fastverdiparametere bruker tildelingsoperatøren som i:

forfatter = "Baeldung"

Mens standardverdier bruker en annen type oppdrag:

forfatter? = "Baeldung"

Vi bruker ?= operatør som betinget tilordner Baeldung til forfatter i tilfelle forfatter er funnet å ikke inneholde noen verdi.

For å få en komplett demonstrasjon, la oss lage HomeController.writer handling. La oss si, bortsett fra forfatterens navn som er en styparameter, vil vi også passere forfatteren id som en søkeparameter som skal være standard til 1 hvis ikke bestått i forespørselen.

Vi endrer oss forfatter handling for å:

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 (forfatter: String, id: Int? = 1)

Laster // localhost: 9000 / skribent vi ser:

Routing in Play av: Baeldung ID: 1

Treffer // localhost: 9000 / skribent? id = 10 gir oss:

Routing in Play av: Baeldung ID: 10

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

Routing in Play av: john ID: 1

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

Routing in Play av: john ID: 5

9. Konklusjon

I denne artikkelen undersøkte vi forestillingen om ruting i Play-applikasjoner. Vi har også en artikkel om å bygge en RESTful API med Play Framework hvor rutingkonseptene i denne opplæringen blir brukt i et praktisk eksempel.

Som vanlig er kildekoden for denne opplæringen tilgjengelig på GitHub.