Útválasztás Java alkalmazásokban

1. Áttekintés

Az útválasztás egy általános fogalom, amely a legtöbb webfejlesztési keretrendszerben megjelenik, beleértve a Spring MVC-t is.

Az útvonal egy URL-minta, amely egy kezelőhöz van hozzárendelve. A kezelő lehet fizikai fájl, például letölthető eszköz a webalkalmazásban, vagy a kérelmet feldolgozó osztály, például vezérlő egy MVC alkalmazásban.

Ebben az oktatóanyagban megvizsgáljuk az útválasztás szempontját a webes alkalmazások fejlesztése során a Play keretrendszerrel.

2. Beállítás

Először létre kell hoznunk egy Java Play alkalmazást. A Play Framework gépen történő beállításának részletei a bevezető cikkünkben találhatók.

A beállítás végére rendelkeznünk kell egy működő Play alkalmazással, amelyet egy böngészőből érhetünk el.

3. HTTP útválasztás

Tehát honnan tudja a Play, hogy melyik vezérlőhöz kell fordulni, amikor HTTP-kérést küldünk? A válasz erre a kérdésre a alkalmazás / konf / útvonalak konfigurációs fájl.

A Play útválasztója a HTTP kéréseket cselekvési hívássá alakítja. A HTTP kéréseket eseményeknek tekintik az MVC architektúrában és az útválasztó reagál rájuk a útvonalak fájl melyik vezérlőnek és melyik műveletet hajtja végre a vezérlőben.

Ezen események mindegyike két paraméterrel látja el az útválasztót: egy kérés elérési útját a lekérdezési karakterlánccal és a kérés HTTP módszerét.

4. Alapvető játékirányítás

Az útválasztó munkájának elvégzéséhez a konf / útvonalak a fájlnak meg kell határoznia a HTTP metódusok és az URI minták leképezését a megfelelő vezérlő műveletekhez:

GET / controllers.HomeController.index GET / asset / * fájl vezérlők.Assets.versioned (elérési út = "/ public", fájl: Asset)

Az összes útvonalfájlnak fel kell térképeznie a statikus erőforrásokat is a play-routing / public a kliens számára elérhető mappa a / vagyon végpont.

Figyelje meg a HTTP-útvonalak és a HTTP-módszer megadásának szintaxisát tér URI minta tér vezérlő akció.

5. URI minták

Ebben a részben egy kicsit kifejtjük az URI mintákat.

5.1. Statikus URI minták

A fenti első három URI minta statikus. Ez azt jelenti, hogy az URL-ek erőforrásokhoz való hozzárendelése minden további feldolgozás nélkül történik a vezérlő műveleteiben.

Amíg egy vezérlő metódust hívnak meg, egy statikus erőforrást ad vissza, amelynek tartalmát a kérés előtt határozzák meg.

5.2. Dinamikus URI minták

A fenti utolsó URI minta dinamikus. Ez azt jelenti, hogy az ezeken az URI-kon egy kérést kiszolgáló vezérlő műveletnek szüksége van a kérelem néhány információjára a válasz meghatározásához. A fenti esetben fájlnévre számít.

Az események szokásos sorrendje az, hogy az útválasztó fogad egy eseményt, kiválasztja az elérési utat az URL-ből, dekódolja annak szegmenseit és továbbítja azokat a vezérlőnek.

Ezután az útvonal és a lekérdezés paramétereit paraméterként a vezérlő műveletébe injektálják. Ezt a következő szakaszokban bemutatjuk egy példával.

6. Haladó útválasztás játékkal

Ebben a szakaszban részletesen megvitatjuk a dinamikus URI minták használatával történő továbbítás speciális lehetőségeit.

6.1. Egyszerű elérési út paraméterek

Az egyszerű elérési út paraméterek a kérelem URL-jében meg nem nevezett paraméterek, amelyek a gazdagép és a port után jelennek meg, és megjelenésük sorrendjében vannak elemezve.

Belül play-routing / app / HomeController.java, hozzunk létre egy új műveletet:

public Eredmény üdvözlet (karakterlánc neve) {return ok ("Hello" + név); }

Szeretnénk tudni kiválasztani a path URL-t a kérés URL-jéből, és feltérképezni a változó nevére.

Az útválasztó ezeket az értékeket az útvonal konfigurációjából kapja meg.

Tehát, nyissuk meg play-routing / conf / útvonalak és hozzon létre egy térképet ehhez az új művelethez:

GET / greet /: névvezérlők. HomeController.greet (név: String)

Figyelje meg, hogyan tájékoztatjuk az útválasztót arról, hogy a név egy dinamikus útvonal-szakasz a kettőspont szintaxissal, majd folytassa, hogy továbbítsa paraméterként az üdvözlő művelet hívásának.

Most töltsük be // locahost: 9000 / greet / john a böngészőben, és név szerint fogunk fogadni:

Szia John

Így történik ha az akcióparaméterünk karakterlánc típusú, akkor a művelethívás során átadhatjuk a paramétertípus megadása nélkül, bár ez más típusokkal nem azonos.

Fűszerezzük a mi /üdvözöl végpont életkori információkkal.

Vissza a HomeControllerÜdvözlő akcióját, a következőre változtatjuk:

public Eredmény üdvözlet (karakterlánc neve, int kor) {return ok ("Hello" + név + ", Ön" + kor + "éves"); }

És az út:

GET / greet /: név /: életkor-szabályozók. HomeController.greet (név: karakterlánc, életkor: egész szám)

Vegye figyelembe a Scala szintaxist is egy változó deklarálásához, kor: Egész szám. Java-ban a Egész életkor szintaxis. A Play Framework Scalában épül fel. Következésképpen sok a scala szintaxis.

Töltsük be // localhost: 9000 / greet / john / 26:

Szia john, 26 éves vagy

6.2. Helyettesítő karakterek az útvonal-paraméterekben

Az útvonalak konfigurációs fájljában az utolsó leképezés a következő:

GET / asset / * fájlvezérlők.Assets.versioned (elérési út = "/ public", fájl: Eszköz)

Az útvonal dinamikus részében helyettesítő karaktert használunk. A Playnek azt mondjuk, hogy bármilyen érték váltja fel * fájl a tényleges kérésben elemezni kell, mint egészet, és nem dekódolni, mint az útvonal-paraméterek más eseteiben.

Ebben a példában a vezérlő egy beépített, Eszközök, amely lehetővé teszi az ügyfél számára fájlok letöltését a play-routing / public mappába. Amikor betöltünk //localhost:9000/assets/images/favicon.png, látnunk kell a Play favicon képét a böngészőben, mivel az megtalálható a / public / images mappába.

Készítsük el saját példaműveletünket HomeController.java:

public Result introdMe (String adatok) {String [] clientData = data.split (","); return ok ("A neved" + clientData [0] + ", te" + clientData [1] + "éves"); }

Figyelje meg, hogy ebben a műveletben egy String paramétert kapunk, és logikánkat alkalmazzuk annak dekódolásához. Ebben az esetben a logika egy vesszővel elválasztott Húr tömbbe. Korábban egy útválasztótól függöttünk, hogy dekódoljuk ezeket az adatokat számunkra.

Helyettesítő karakterekkel önmagunk vagyunk. Reméljük, hogy az ügyfél a szintaxisunkat helyesvé teszi, miközben továbbítja ezeket az adatokat. Ideális esetben használat előtt ellenőriznünk kell a bejövő karakterláncot.

Hozzunk létre egy útvonalat ehhez a művelethez:

GET / * adatkezelők. HomeController.introduceMe (adatok)

Most töltse be az URL-t // localhost: 9000 / john, 26. Ez kinyomtatja:

A neved john, 26 éves vagy

6.3. Regex az útvonal-paraméterekben

A helyettesítő karakterekhez hasonlóan használhatunk reguláris kifejezéseket a dinamikus részhez. Adjunk hozzá egy olyan műveletet, amely számot kap, és visszaadja a négyzetét:

public Result squareMe (Long num) {return ok (num + "A négyzet értéke" + (num * num)); }

Most hozzáadjuk az útvonalát:

GET / square / $ num vezérlők. HomeController.squareMe (szám: Long)

Helyezzük ezt az útvonalat a mutass be új koncepció bevezetésére. Csak akkor tudjuk kezelni az útvonalakat, ahol a regex rész pozitív egész szám, ezzel az útválasztási konfigurációval.

Most, ha az útvonalat az előző bekezdésben leírtak szerint helyeztük el, és betöltjük // localhost: 9000 / négyzet / 2, egy-vel kell fogadnunk ArrayIndexOutOfBoundsException:

Ha ellenőrizzük a kiszolgálói konzol hibanaplóit, rájövünk, hogy az akcióhívást valóban végrehajtották mutass be akció helyett squareMe akció. Mint korábban a helyettesítő karakterekről elmondtuk, önmagunk vagyunk, és nem validáltuk a bejövő adatokat.

Vesszővel elválasztott karakterlánc helyett a mutass be metódust a „négyzet / 2“. Következésképpen, miután felosztottuk, egy első méretű tömböt kaptunk. Megpróbál elérni indexet 1 aztán dobta a kivételt.

Természetesen azt várnánk, hogy a hívás a squareMe módszer. Miért irányították mutass be? Ennek oka egy olyan Play funkció, amelyet a következő nevezünk Routing Priority.

7. Útvonal-prioritás

Ha konfliktus van az útvonalak között, mint a között squareMe és mutass be, azután A Play kiválasztja az első útvonalat deklarációs sorrendben.

Miért van konfliktus? A helyettesítő szöveges összefüggési út miatt /*adat megegyezik a kérelem URL-jével, az alap elérési útján kívül /. Így minden olyan útvonalnak, amelynek URI mintája helyettesítő karaktereket használ, a sorrendben utoljára kell megjelenni.

Most változtassuk meg az útvonalak deklarációs sorrendjét úgy, hogy a mutass be útvonal jön utána squareMe és töltsd újra:

2 A négyzet négyzet

Az útvonalon található reguláris kifejezések erejének teszteléséhez próbálja meg betölteni // locahost: 9000 / négyzet / -1, egy útválasztó nem fog megfelelni a squareMe útvonal. Ehelyett meg fog egyezni mutass be, és megkapjuk a ArrayIndexOutOfBoundsException újra.

Ez azért van, mert -1 nem egyezik a megadott reguláris kifejezéssel, és egyetlen ábécés karakter sem.

8. Paraméterek

Eddig a pontig áttekintettük a paramétertípusok deklarálásának szintaxisát az útvonalfájlban.

Ebben a szakaszban további lehetőségeket vizsgálunk meg, amikor az útvonalak paramétereivel foglalkozunk.

8.1. Paraméterek rögzített értékekkel

Néha fix értéket akarunk használni egy paraméterhez. Így tudjuk megmondani a Playnek, hogy használja a megadott elérési utat, vagy ha a kérési kontextus az elérési út /, majd használjon egy bizonyos rögzített értéket.

Megtekintésének másik módja az, hogy két végpont vagy kontextus útvonal van ugyanazon vezérlő művelethez vezetve - az egyik végpontnak meg kell adnia egy paramétert a kérés URL-jétől, és a másiknak alapértelmezettnek kell lennie abban az esetben, ha az említett paraméter hiányzik.

Ennek bemutatásához tegyünk hozzá egy a-t író() cselekvés a HomeController:

public Result író () {return ok ("Baeldung útvonala a játékban"); }

Feltéve, hogy nem mindig akarjuk, hogy az API-nk visszatérjen a Húr:

Routing a Playben Baeldung által

Ezt úgy akarjuk ellenőrizni, hogy a cikk szerzőjének nevét elküldjük a kéréssel együtt, alapértelmezés szerint a rögzített érték mellett Baeldung csak akkor, ha a kérelem nem rendelkezik a szerző paraméter.

Tehát változtassunk tovább a író művelet egy paraméter hozzáadásával:

public Result író (karakterlánc-szerző) {return ok ("REST API with Play by" + szerző); }

Lássuk azt is, hogyan adhatunk fix értékű paramétert az útvonalhoz:

GET / író vezérlők.HomeController.writer (szerző = "Baeldung") GET / író /: szerző vezérlők.HomeController.writer (szerző: karakterlánc)

Figyelje meg, hogyan van most két külön útvonalunk, amelyek mind a HomeController.index akció egy helyett.

Amikor most betöltünk // localhost: 9000 / író a böngészőből kapjuk:

Routing a Playben Baeldung által

És amikor betöltünk // localhost: 9000 / író / john, kapunk:

Útvezetés a Playben John által

8.2. Paraméterek alapértelmezett értékekkel

A paraméterek rögzített értékek mellett alapértelmezett értékekkel is rendelkezhetnek. Mindkettő tartalékértékeket ad a vezérlő műveleti paramétereinek, ha a kérelem nem adja meg a szükséges értékeket.

A kettő közötti különbség az a rögzített értékeket az útvonal-paraméterek tartalékaként, míg az alapértelmezett értékeket a lekérdezési paraméterek tartalékaként használják.

Az útvonal paraméterei formájúak // localhost: 9000 / param1 / param2 és a lekérdezési paraméterek formájúak // localhost: 9000 /? param1 = érték1¶m2 = érték2.

A második különbség abban áll, hogy a kettőt egy útvonalon deklaráljuk. A fix értékű paraméterek a hozzárendelés operátorát használják:

szerző = "Baeldung"

Míg az alapértelmezett értékek más típusú hozzárendelést használnak:

szerző? = "Baeldung"

Használjuk a ?= operátor, amely feltételesen hozzárendel Baeldung nak nek szerző Amennyiben szerző megállapítást nyert, hogy nem tartalmaz értéket.

A teljes bemutatáshoz készítsük el a HomeController.writer akció. Tegyük fel, hogy a szerző nevén kívül, amely elérési út paraméter, a szerzőt is át akarjuk adni id lekérdezési paraméterként, amelynek alapértelmezés szerint a 1 ha nem felel meg a kérelemnek.

Megváltozunk író cselekvés:

public Eredményíró (karakterlánc-író, int id) {return ok ("Routing in Play by:" + author + "ID:" + id); }

és a író útvonalak ide:

GET / író vezérlők.HomeController.writer (szerző = "Baeldung", id: Int? = 1) GET / író /: szerző vezérlők.HomeController.writer (szerző: String, id: Int? = 1)

Most betöltődik // localhost: 9000 / író látjuk:

Routing a Play-ben: Baeldung ID: 1

Ütés // localhost: 9000 / író? id = 10 ad nekünk:

Routing a Play-ben: Baeldung ID: 10

Mit szólsz // localhost: 9000 / író / john?

Útvonal a Playben: John ID: 1

És végül, // localhost: 9000 / író / john? id = 5 visszatér:

Útvonal a Playben: john ID: 5

9. Következtetés

Ebben a cikkben az Routing in Play alkalmazások fogalmát tártuk fel. Van egy cikkünk is egy RESTful API Play keretrendszerrel felépítéséről, ahol az oktatóanyag útválasztási koncepcióit gyakorlati példában alkalmazzuk.

Szokás szerint az oktatóanyag forráskódja elérhető a GitHubon.


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