Útvonalak és erőforrások

alapvető Routing konvenciók

vessünk egy pillantást az útvonalakra, ahogy most vannak, a rake routes:

$ rake routes Prefix Verb URI Pattern Controller#Action list_posts GET /list_posts(.:format) application#list_posts GET /show_post/:id(.:format) application#show_post new_post GET /new_post(.:format) application#new_post create_post POST /create_post(.:format) application#create_post GET /edit_post/:id(.:format) application#edit_post POST /update_post/:id(.:format) application#update_post POST /delete_post/:id(.:format) application#delete_post POST /create_comment_for_post/:post_id(.:format) application#create_comment POST /list_posts/:post_id/delete_comment/:comment_id(.:format) application#delete_comment list_comments GET /list_comments(.:format) application#list_comments 

a Rails-egyezmények egyik legfontosabb meglátása, hogy az adatközpontú alkalmazások (vagy durva alkalmazások) általában nagyon hasonló módon engedik a felhasználóknak az alkalmazással való interakciót, amelyek a következők:

• egy oldal valaminek a listájának megtekintéséhez
• valaminek a megtekintése
• űrlap megjelenítése valaminek egy új példányának létrehozásához
• valójában létrehoz valamit
• űrlap megjelenítése valaminek egy példányának szerkesztéséhez
• valójában frissít valamit
• töröl valamit

ez a hét “interakciós minta” olyan gyakori, hogy a Rails az útválasztástól a vezérlőkig, a nézetekig és az űrlapokig terjedő konvenciók erős halmazát biztosítja a munkafolyamatok egyszerűbbé tételéhez. Most a routing részre fogunk koncentrálni.

az útválasztásnál az a konvenció, hogy ahelyett, hogy nekünk kellene előállnunk az URL-mintákkal, a Rails azt javasolja, hogy az URL-eket és a megfelelő vezérlőműveleteket a következő módon strukturáljuk:

munkafolyamat	HTTP ige	elérési út	vezérlő művelet
a bejegyzések listájának megjelenítése	GET	/ Hozzászólások	Hozzászólások#index
bejegyzés megjelenítése	GET	/ Hozzászólások/:id	Hozzászólások # show
az oldal megjelenítése a bejegyzés létrehozásához	GET	/ posts / new	posts # new
bejegyzés létrehozása	bejegyzés	/ bejegyzések	bejegyzések # létrehozás
a bejegyzés szerkesztéséhez szükséges oldal megjelenítése	GET	/ posts/: id / edit	posts # edit
frissítsen egy bejegyzést	PUT / PATCH	/ Hozzászólások/: id	Hozzászólások # frissítés
bejegyzés törlése	törlés	/ Hozzászólások/:id	Hozzászólások # elpusztítani

megváltoztathatjuk jelenlegi útvonalunk post részét, hogy kövessük ezt az egyezményt:

# posts GET /list_posts -> GET /posts posts#index GET /show_post/:id -> GET /posts/:id posts#show GET /new_post -> GET /posts/new posts#new POST /create_post -> POST /posts posts#create GET /edit_post/:id -> GET /posts/:id/edit posts#edit POST /update_post/:id -> PUT/PATCH /posts/:id posts#update POST /delete_post/:id -> DELETE /posts/:id posts#destroy 

és a routes.rb fájlban,

Rails.application.routes.draw do ### posts ### get '/posts' => 'posts#index' get '/posts/new' => 'posts#new' get '/posts/:id' => 'posts#show' post '/posts' => 'posts#create' get '/posts/:id/edit' => 'posts#edit' patch '/posts/:id' => 'posts#update' put '/posts/:id' => 'posts#update' delete '/posts/:id' => 'posts#destroy' # comments later.. ... end 

vegye figyelembe, hogy ezzel az új mintával, sokkal kevesebb ige van magában az URL-ben, de a HTTP-igékre támaszkodunk (GET/POST/PUT/PATCH/DELETE) az egyébként azonos URL-minták szemantikájának megadása, például /posts/:id.

vegye figyelembe, hogy az PUT – ot az erőforrások frissítésére használták egészen a közelmúltig, amikor az PATCH jobb szemantikai egyezést mutatott ehhez a művelethez. Azóta a Rails a PATCH előnyben részesítésére költözött, de mindkét igét engedélyezte a frissítésekhez.

egy másik változás, amelyet később látni fogunk, az, hogy a bejegyzésekhez kapcsolódó összes URL-t PostsController – re irányítjuk, ahelyett, hogy mindent ApplicationController – ben kezelnénk. A PostController‘s action names

• új
• index
• show
• create
• edit
• update
• destroy

szintén konvenciók megfelelő a 7 interakció minták.

ez a legerősebb konvenciók, hogy Rails ró rád, mint egy alkalmazás fejlesztő. Arra kérjük, hogy próbáljon meg memorizálni. Majd újra ezt a rengeteg alkalommal az egész könyvet, hogy segítsen csinálni, hogy is.

több erőforrás útválasztása

gyakran több erőforrásra van szükségünk az URL-ben. Például a blogalkalmazásunkhoz, amikor szükségünk van egy útvonalra a megjegyzés létrehozásához, nagyon fontos, hogy tudjuk, melyik bejegyzéshez jön létre ez a megjegyzés.

jelenleg ezt csináljuk:

post 'create_comment_for_post/:post_id' => 'application#create_comment' 

a több társított erőforrással rendelkező URL-ek Rails konvenciója a “tartalmazó” erőforrással kezdődik egészen a “legbelső” erőforrásig. Például a Megjegyzések útvonalai megváltoznának:

post '/posts/:id/comments' => 'comments#create' delete '/posts/:post_id/comments/:id' => 'comments#destroy' get '/comments' => 'comments#index' 

ezeknek az URL-eknek a szemantikája a következőket jelenti:” megjegyzés létrehozása egy adott bejegyzés alatt “és”Megjegyzés törlése egy adott bejegyzés alatt”. Az utolsó útvonalat, “az összes Megjegyzés megjelenítése a rendszerben”, nem kell” hatókörrel “ellátni egy bejegyzés alatt, így az URL-nek nem kell a”/posts ” betűvel vezetnie.

ha több erőforrásra van szükségünk az URL-ben az Azonosítóikkal, akkor a konvenció olyan, hogy az utolsó erőforrás a :id helyőrzőt fogja használni, a többi pedig :resource_idlesz, például :post_id.

Restful

a REST jelentése “Reprezentációs Állapotátadás”. Ez egy szoftver architektúra stílus és iránymutatás a skálázható webszolgáltatások létrehozásához. A rest, mint a webes alkalmazások strukturálásának módja, számos aspektussal rendelkezik, de nézzük csak meg, hogyan vonatkozik arra a felületre, amelyet a webes alkalmazásokkal, az URL-ekkel való interakcióhoz használunk.

ha meg szeretné tudni, hogy a REST hogyan egyszerűsíti az URL-ek szemantikáját, nézzünk át egy példát. Tegyük fel, hogy online pizza rendelési szolgáltatást építünk. A szolgáltatás interfészeinek (URL-ek) na 6VE megvalósítása a következő lenne:

/check_order?order_id=2 /place_new_order /pizza_details?type=1 /pay_for_my_order?order_id=12 /cancel_order?order_id=3 /expedite_order?order_id=13 

a nyugodt felület kialakítása így nézne ki:

GET /orders/2 POST /orders GET /pizzas/1 POST /orders/12/payments DELETE /orders/3 POST /orders/13/expeditions 

láthatja, hogy a RESTful interfészek a “főnevek” vagy az “erőforrások” köré összpontosulnak, eltávolítva az” igéket ” az interfészekből, ehelyett a szabványosított HTTP igékre támaszkodva (GET/POST/PUT/DELETE) hogy nyers szemantikát biztosítson az akciókhoz. Igék, mint például check, place, cancel közvetlenül a GET lekéréséhez, POST létrehozásához és DELETE a ordererőforrás megsemmisítéséhez tartozó HTTP igékhez vannak leképezve. A pay és a expedite a payments és a expeditionsalerőforrások létrehozása (HTTP POST) a orders erőforrás alatt.

RESTful interfaces szabványosított webes alkalmazás interakciós minták, hogy azok könnyebben érthető és a program ellen. Mivel az interfészek az erőforrások manipulálására összpontosítanak, a válaszok sokkal kiszámíthatóbbak. Annak analógiája, hogy a RESTful architektúra minta hogyan egyszerűsíti a webszolgáltatásokkal való interakciót, az lenne, hogy a relációs adatbázis és az SQL nyelv hogyan egyszerűsíti az adattárolást. A relációs adatbázis és az SQL előtt az adatokat általában szabadalmaztatott rendszerekben tárolták, speciális logikával, hogy kölcsönhatásba lépjenek velük, ez azt jelentette, hogy minden projektnél más utasításokat kell megtanulnia az adatokkal való interakcióhoz. A relációs adatbázisok és az SQL közös adatstruktúrát adott (adatrekordok táblázatokban tárolt sorokként és oszlopokként), valamint közös interfészek halmazát-négy egyszerű igét SELECT, INSERT, UPDATE és DELETE, amely minden típusú alkalmazást támogat.

a RESTful felület alkalmazása a webalkalmazáshoz is egyszerűsíti az alkalmazást, hogy igazodjon a háttéradatok adatbázisokban történő tárolásához, és megkönnyíti a fejlesztést. Ezt a következő fejezetekben fogjuk látni.

Forrásjelölés

beszéltünk a Rails útválasztási konvencióiról és a RESTful URL-mintákról. Most a routes.rb fájlunk a következőképpen néz ki:

### config/routes.rb ### Rails.application.routes.draw do ### posts ### get '/posts' => 'posts#index' get '/posts/new' => 'posts#new' get '/posts/:id' => 'posts#show' post '/posts' => 'posts#create' get '/posts/:id/edit' => 'posts#edit' patch '/posts/:id' => 'posts#update' put '/posts/:id' => 'posts#update' delete '/posts/:id' => 'posts#destroy' ### comments ### get '/comments' => 'comments#index' post '/posts/:id/comments' => 'comments#create' delete '/posts/:post_id/comments/:id' => 'comments#destroy' end 

valójában az olyan útvonalak, mint amilyenek a posts szakaszban vannak, nagyon gyakoriak, ezért a Rails egy speciális resources jelölést biztosít, amely segít létrehozni ezeket az Ön számára.

egyszerűen megtehetjük:

resources :posts 

ez a sor automatikusan generálja a korábban meglévő 8 sort. Vegye figyelembe ,hogy a update művelethez a sínek kompatibilitási okokból mind a PUT, mind a PATCH igét engedélyezik.

a bundle exec rake routes parancssori környezetben futtathatja annak ellenőrzését, hogy pontosan ugyanazokat az útvonalakat generálja-e.

vegye figyelembe, hogy ez az egyetlen vonal 8 útvonalat generál. Esetünkben itt minden útvonalra szükségünk van, de ha csak az útvonalak egy részhalmazára van szüksége, akkor explicitebben definiálhatja őket:

resources :posts, only: 

ez a fenti sor csak 3 útvonalat generál az Ön számára-írja be a bundle exec rake routes parancsot, hogy ellenőrizze.

beágyazott erőforrások

a Rails lehetővé teszi az erőforrások beágyazását több erőforrással rendelkező URL-minták létrehozásához, lásd alább:

### config/routes.rb ### Rails.application.routes.draw do resources :posts do resources :comments, only: end resources :comments, only: :index end 

futtassa a bundle exec rake routes parancsot, és nézze meg a kimenetet – ugyanolyannak kell lennie, mint korábban.

útvonal-segítők

a bundle exec rake routes futtatásakor vegye figyelembe az Prefix oszlopot ezen útvonalak némelyikéhez. Ezek azért vannak itt, hogy segítsenek nekünk tudni, hogyan kell használni a sínek által biztosított útsegítőket útvonalainkhoz. Ezeket az előtagokat _path követhetjük kontrollereinkben és nézeteinkben, hogy könnyen építsünk útvonalakat.

például:

posts_path # => '/posts' post_id = 123 post_comments_path(post_id) # => '/posts/123/comments' 

mi az előnye az URL-segítők használatának, ahelyett, hogy keményen kódolná az útvonalakat, például /posts/123/comments közvetlenül a kódban? (például a vezérlő műveletében?) Az útvonal-segítők használatának oka az, hogy ha meg akarja változtatni az alkalmazás URL-mintáit, akkor sokkal könnyebb az URL-segítőket használni egy másik útvonal visszaadásához – nézzünk meg egy példát:

get '/register', to: 'users#new', as: 'register' 

amikor hozzáadjuk az” as ” záradékot ehhez az útvonalhoz, ha a bundle exec rake routes parancsot futtatja, akkor a Prefix oszlop jelenik meg a register értékkel, és a register_path használatával megkaphatja a /register elérési utat. Most, ha meg akarjuk változtatni az utat /login – ra, csak annyit kell tennünk, hogy:

get '/login', to: 'users#new', as: 'register' 

most a register_pathad nekünk /login. Egyáltalán nem kell megváltoztatnunk a kódot a Rails alkalmazásban.

további Routing konvenciók

mielőtt továbblépnénk, vessünk egy gyors pillantást a már látott néhány variációra, valamint néhány más, a Rails routingban elérhető funkcióra:

### config/routes.rb ### Rails.application.routes.draw do # pointing our homepage (root path) to posts#index root to: 'posts#index' # `match` & `via:` allow us to define one route and use several HTTP verbs # `as:` lets us define the name of the route prefix match '/authors/:id' => 'authors#update', via: , as: :update_author # update_author PUT|PATCH /authors/:id(.:format) authors#update resources :posts do # define extra params to pass for requests to a route get 'popular', on: :collection, action: :index, popular: true # popular_posts GET /posts/popular(.:format) posts#index {:popular=>true} get 'preview', on: :member # ... end # we can even use routes to redirect get '/home', to: redirect('/') end 

bontsuk le egyenként a fent felsorolt összes funkciót.

• root: root annak megadására szolgál, hogy milyen műveletet térképezzen a “/”-re(webhelyünk legfelső szintű URL-je, amelynek nincs elérési útja).A webhely/alkalmazás gyökér URL-je a leggyakrabban használt, ezért root meg kell adniaz útvonalak fájl tetején.

• mérkőzés + keresztül: A match az URL-minták egy vagy több útvonalhoz való illesztésére szolgál. Megadhatjuk azt is, hogy melyik HTTP-ige használható az ezzel a mintával rendelkező URL-hez való illesztéshez. Ezt úgy végezzük, hogy egy hash-ot adunk át a match metódusnak. Ennek a kivonatnak a kulcsa via, az érték pedig HTTP-igék tömbje. A match néhány általánosabb célú HTTP-útválasztási módszer, mint például a get, postés delete. Lehet, hogy ugyanazokat a lehetőségeket veszi igénybe, mint ezek a módszerek, de ezekhez a módszerekhez képest egy kicsit nagyobb rugalmasságot biztosít.
  például a match használatával megadhatunk egy URL-t, amely két különböző útvonalnak felel meg, amelyek mindegyike két különböző HTTP-igének felel meg. Általában ehhez két parancsra lenne szükség, egy helyett. Ezt láthatjuk a fenti példánkból, ahol a '/authors/:id' URL-mintát illesztjük a 'authors#update'művelethez. Ezután megadjuk, hogy milyen HTTP-igék használhatók az adott URL-re vonatkozó kérés kiadására via: . A match használatakor mindig adjon meg egy HTTP-módszert, ennek elmulasztása negatív hatással lehet az alkalmazás biztonságára.A
  match egy másik lehetőséget mutat be a Rails bizonyos műveleteinek útválasztásához. Általában a legjobb, ha a leggyakrabban használt HttpHelpers módszereket alkalmazzuk, mint például a get és a post.

• mint: egy kicsit korábban említettük, hogy a as: opció használható az útvonal-deklarációval az URL-segítők előtagjának megváltoztatásához. Ezt különféle módon lehet felhasználni. Használhatjuk a as: – et, hogy az URL-segítőink jobban illeszkedjenek az egyéni URL-ekhez. Egy másik felhasználás az aktuális URL-útvonal-segítő megváltoztatása valami intuitívabbá, vagy valami olyanra, amely jobban illeszkedik az alkalmazáson belüli erőforrásokhoz.

• gyűjtési útvonal: nézze meg, hogyan fészkeljük be a /popular útvonalat a posts erőforrás alatt. Ezután a on: :collection – et használjuk annak meghatározására, hogy egy erőforrás mely része alatt fészkeljük be ezt az útvonalat. Van sok hozzászólás, így tekinthető a gyűjtemény. A on: :collection megadásával azt mondjuk, hogy “illesszen egy URL-t a /posts/popularelérési úttal.”Ha nem adtuk hozzá a on: :collection értéket, a Rails feltételezi, hogy ez az útvonal egy másik erőforrásnak felel meg, amely a bejegyzésgyűjteményünk egyetlen tagjához kapcsolódik. Ebben az esetben az útvonalunk /posts/:id/popularlesz. Több gyűjtési útvonalat is megadhatunk blokk formátum használatával.

collection do get 'popular' end 

• extra paraméter átadása: megadhatunk egy alapértelmezett paramétert, amelyet mindig a params hash-val adunk át, amikor bizonyos URL-ekkel egyeztetünk. Kétféle módon lehet ezt meghatározni; az egyik út ugyanúgy történik, mint fent:

get 'popular', on: :collection, action: :index, popular: true 

popular: true a params hash segítségével a népszerű útvonal megegyezik a műveletünkkel. A kulcs :popular és truelesz. Kifejezettebb szintaxist is használhatunk, ha egy kivonatot továbbítunk a get útvonalmódszerünkhöz, ahol a kulcs defaults:, az érték pedig egy másik hash, amely tartalmazza annak a paraméternek a nevét, amelyet át akarunk adni a műveletünknek.

get 'popular', on: :collection, action: :index, defaults: { popular: true} 

• tag útvonal: a on: member használatával megadhatjuk, hogy az útvonalunk egy gyűjtemény tagjához illeszkedjen. Ha ezt használjuk, akkor a dinamikus szegmens :idlesz. Egy URL segítő is létrejön preview_postnéven. Ha ezt az útvonalat on: member – vel adjuk meg, azt mondjuk a Rails-nek, hogy ez az adott erőforrás tagja. Hogy ez nem csak egy másik, a bejegyzések alá ágyazott erőforrás, hanem szorosabban kapcsolódik vagy kapcsolódik az alkalmazásban szereplő bejegyzéseinkhez. Több tag útvonalát blokkformátummal lehet meghatározni; ez a formátum ugyanazt a szintaxist használja, mint a blokk formátum több gyűjtési útvonal meghatározásához, csak cserélje le a collection – et member – re.

• átirányítás: van még egy fogalom, amiről beszélni kell, ami megjelenik a fenti példánkban, ez pedig az átirányítás. A Rails lehetőséget ad arra, hogy átirányítsuk az egyik útvonalról a másikra egy átirányítási segítő használatával egy útvonallal együtt.get '/home', to: redirect('/'). Ha valaki megpróbálja elérni a /home elérési utat, akkor azonnal átirányítja a /gyökérútvonalra. Ez természetesen nem korlátozódik csak egy URL-útvonalra; lehet valami ilyesmi is: get '/home', to: redirect('/travel').

felülvizsgálat

a sínpályák az alkalmazás előtt állnak. Egy útvonal értelmezi a bejövő HTTP kérést és:

• http-igék és kérés URL-minta kombinációján alapuló kérés illesztése egy vezérlőművelethez
• adatokat rögzít az URL-ben, hogy elérhető legyen a params vezérlőműveletekben
• a Rails arra ösztönzi a fejlesztőket, hogy RESTful URL-mintákat használjanak az útvonalak beállításakor, az erőforrások HTTP-igékkel történő manipulálásának konceptualizálásával.
• a resources makró segítségével nagyon gyorsan létrehozhat RESTful útvonalakat.