Reitit ja resurssit

Perusreittikäytännöt

Katsotaanpa reittejämme sellaisina kuin ne ovat nyt, käyttäen 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 

yksi Rails-konventioiden keskeisistä oivalluksista on, että datakeskeisillä sovelluksilla (tai karkeilla sovelluksilla) on yleensä hyvin samanlaiset tavat antaa käyttäjien olla vuorovaikutuksessa sovelluksen kanssa, jotka ovat:

• a page to view a list of something
• view something
• show a form to create a new instance of something
• actually create something
• show a form to edit an instance of something
• actually update something
• delete something

nämä seitsemän ”vuorovaikutusmallia” ovat niin yleisiä, että rails tarjoaa vahvan joukon konventioita reitityksistä ohjaimiin, näkymiin ja lomakkeisiin, jotka helpottavat näitä työnkulkuja. Keskitymme nyt reititykseen.

reitityksen osalta käytäntönä on, että sen sijaan, että meidän täytyisi keksiä URL-osoitteiden kuviot, Rails suosittelee, että Jäsennämme URL-osoitteet ja vastaavat ohjaimen toiminnot seuraavalla tavalla:

työnkulku	HTTP-verbi	polku	ohjaimen toiminta
Näytä luettelo posteista	GET	/ posts	posts#index
Näytä viesti	GET	/ viestit/:id	viestit#Näytä
Näytä sivu luodaksesi post	GET	/ posts / new	posts#new
Create a post	POST	/ posts	posts#create
Näytä sivu muokataksesi viestiä	GET	/ posts/: id / edit	posts#edit
Update a post	PUT/PATCH	/ posts/: id	posts#update
Delete a post	DELETE	/ posts/:id	posts#destroy

voimme muuttaa post – osan nykyisestä reitistämme tämän yleissopimuksen mukaiseksi:

# 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 

ja routes.rb – tiedostossa,

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 

huomaa, että tämä uusi malli, siellä on paljon vähemmän verbejä URL itse, mutta olemme riippuvaisia HTTP-verbit (GET/POST/PUT/PATCH/DELETE) toimittaa semantiikkaa muuten samoille URL-kuvioille, esimerkiksi /posts/:id.

huomaa, että PUT oli käytetty resurssien päivittämiseen viime aikoihin asti, jolloin PATCH todettiin olevan parempi semanttinen vastine tälle toiminnalle. Sittemmin Rails on siirtynyt suosimaan PATCH, mutta sallinut molemmat verbit päivityksiin.

toinen muutos, jonka näemme myöhemmin, on se, että reititämme kaikki viesteihin liittyvät URL-osoitteet osoitteeseen a PostsController sen sijaan, että käsittelisimme kaikkea ApplicationController. PostControllertoiminnan nimet

• Uusi
• indeksi
• Näytä
• luo
• edit
• päivitys
• tuhota

ovat myös konventioita, jotka vastaavat 7 yhteisvaikutusta kuvioita.

tämä on vahvin konventio, jonka Rails asettaa sinulle sovelluskehittäjänä. Pyydämme sinua opettelemaan sen ulkoa. Palaamme tähän monta kertaa koko kirjan ajan, jotta voit tehdä senkin.

reititys useille resursseille

usein URL-osoitteessa on oltava useita resursseja. Esimerkiksi meidän blogisovellus aina kun tarvitsemme reitin luoda kommentti, se on erittäin tärkeää, että tiedämme, mikä viesti tämä kommentti on luotu.

tätä tehdään parhaillaan:

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

Rails-käytäntö URL-osoitteessa, jossa on useita liitännäisiä resursseja, on aloittaa ”sisältävästä” resurssista aina ”sisimpään” resurssiin saakka. Esimerkiksi kommenttireitit muuttuisivat:

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

näiden URL-osoitteiden semantiikka edustaa: ”luo kommentti tietyn postauksen alle” ja ”poista kommentti tietyn postauksen alle”. Viimeinen reitti, ”Näytä kaikki kommentit järjestelmässä”, ei tarvitse olla” scoped ”alle postitse, joten URL ei tarvitse johtaa”/viestit”.

jos URL-osoitteessa on oltava useita resursseja tunnuksineen, käytäntö on sellainen, että viimeinen resurssi käyttää paikkamerkkiä :id ja kaikki muu on :resource_id kuten :post_id.

levollinen

lepo tarkoittaa ”edustavan Valtion siirtoa”. Se on ohjelmistoarkkitehtuurin tyyli ja ohje skaalautuvien verkkopalveluiden luomiseen. Loput, kuten tapa jäsentää web-sovelluksia, on monia puolia, mutta katsotaanpa vain tarkastella, miten se koskee käyttöliittymä, että käytämme vuorovaikutuksessa web-sovellukset, URL.

nähdäksesi, miten lepo yksinkertaistaa URL-osoitteiden semantiikkaa, käydään esimerkki läpi. Oletetaan, että rakennamme nettipizzan tilauspalvelua. Naiivi toteutus rajapinnat palvelun (URL) olisi:

/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 

levollinen käyttöliittymäsuunnittelu näyttäisi tältä:

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

voit nähdä, levollinen rajapinnat keskus noin ”substantiivit” tai ”resurssit”, poistamalla ”verbit” rajapinnoista, mutta sen sijaan luottaa standardoitu HTTP-verbit (GET/POST/PUT/DELETE) toimittaa CRUD semantiikkaa tekoihin. Verbit kuten check, place, cancel on yhdistetty suoraan HTTP-verbeihin GET hakea, POST luoda ja DELETE tuhota resurssi order. pay ja expedite on rakenteeltaan payments ja expeditions resurssin ordersaliresurssien luominen (HTTP-POST).

levolliset rajapinnat standardoivat web-sovellusten vuorovaikutusmalleja, jotta niitä olisi helpompi ymmärtää ja ohjelmoida vastaan. Koska rajapinnat keskittyvät resurssien manipulointiin, vastaukset ovat paljon ennakoitavampia. Analogia siitä, miten levollinen arkkitehtuurikuvio yksinkertaistaa vuorovaikutusta verkkopalvelujen kanssa, olisi se, miten relaatiotietokanta ja SQL-kieli yksinkertaistavat tiedon tallennusta. Ennen relaatiotietokantaa ja SQL: ää data oli tyypillisesti tallennettu suljettuihin järjestelmiin, joissa oli tietty logiikka vuorovaikutuksessa niiden kanssa, tämä tarkoitti sitä, että jokaisessa projektissa piti opetella erilaiset ohjeet vuorovaikutuksessa datan kanssa. Relaatiotietokannat ja SQL antoivat yhteisen tietorakenteen (tietueet taulukoihin tallennettuina riveinä ja sarakkeina) ja joukon yhteisiä rajapintoja-neljä yksinkertaista verbiä SELECT, INSERT, UPDATE ja DELETE , jotka voivat tukea kaikentyyppisiä sovelluksia.

levollisen käyttöliittymän käyttöönotto verkkosovellukseesi tehostaa myös sovellustasi, jotta se vastaa sitä, miten taustatietoja tallennetaan tietokantoihin, ja helpottaa kehitystä. Näemme sen seuraavissa luvuissa.

Resurssimerkintä

on puhuttu Railsin reitityskonventioista ja Levollisista PAIKANTAMISKUVIOISTA. Nyt routes.rb – tiedostomme näyttäisi seuraavanlaiselta:

### 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 

itse asiassa reitit, kuten mitä meillä on posts osuus ovat hyvin yleisiä, joten Rails tarjoaa erityisen resources merkintä, joka auttaa luomaan ne sinulle.

voimme yksinkertaisesti tehdä:

resources :posts 

tämä linja tuottaa automaattisesti 8 riviä meillä oli ennen. Huomaa, että update – toiminnassa Rails sallii yhteensopivuussyistä sekä PUT että PATCH verbin.

voit suorittaa bundle exec rake routes komentoriviympäristössä varmistaaksesi, että se luo täsmälleen samat reitit.

huomaa, että tällä yhdellä linjalla syntyy 8 reittiä. Meidän tapauksessamme satumme tarvitsemaan kaikki reitit täällä, mutta jos tarvitset vain osajoukon reiteistä, voit määritellä ne tarkemmin::

resources :posts, only: 

Tämä yllä oleva rivi tuottaisi vain 3 reittiä sinulle-tyyppi bundle exec rake routes tarkistaa sen.

sisäkkäiset resurssit

kiskot mahdollistavat myös resurssien peittämisen, jotta voidaan luoda URL-malleja, joissa on useita resursseja, katso alla:

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

Juokse bundle exec rake routes ja katso lähtö – sen pitäisi olla sama kuin mitä meillä oli aiemmin.

Polkuapulaiset

kun juokset bundle exec rake routes, huomaa Prefix – palsta joidenkin näiden reittien kohdalla. Nämä auttavat meitä osaamaan käyttää Railsin tarjoamia polkuapureita reiteillemme. Näitä etuliitteitä, joita seuraa _path, Voimme käyttää ohjaimissamme ja näkymissämme helposti polkujen rakentamiseen.

esimerkiksi:

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

mitä hyötyä on URL-auttajien käyttämisestä sen sijaan, että koodaisit kovalla kädellä polkuja, kuten /posts/123/comments, suoraan koodiisi? (esimerkiksi controller toiminta?) Syy, miksi haluat käyttää path helpers on, että jos haluat muuttaa URL kuvioita sovelluksen, se on paljon helpompi käyttää URL auttajat palata eri polku-katsotaanpa esimerkki:

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

kun tähän reittiin lisätään ”as” – pykälä, jos ajat bundle exec rake routes, näet Prefix sarakkeen, jossa on register, ja voit käyttää register_path saadaksesi /register polun. Jos haluamme muuttaa /login: n tien, meidän on vain:

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

nyt meidän register_path antaa meille /login. Rails-sovelluksen koodia ei tarvitse muuttaa lainkaan.

lisää Reitityskonventioita

ennen kuin siirrymme eteenpäin, vilkaiskaamme pikaisesti paria variaatiota siitä, mitä olemme jo nähneet, sekä joitakin muita ominaisuuksia, joita meillä on Rails routingissa:

### 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 

hajotetaan kaikki edellä luetellut ominaisuudet yksi kerrallaan.

• root: root käytetään määrittämään, mitä toimintakarttoja”/”: iin(sivustomme ylätason URL, jossa ei ole polkua).Sivustosi/sovelluksesi juuriosoite on yleisimmin käytetty, koska tästä syystä root tulisi määritellä routes-tiedoston yläosassa.

• ottelu + kautta: match käytetään URL-kaavojen sovittamiseen yhteen tai useampaan reittiin. Voimme myös määrittää, mitä HTTP-verbiä voidaan käyttää tämän kuvion URL-osoitteen sovittamiseen. Teemme tämän siirtämällä hasiksen match – menetelmään. Avain tähän hash on via, ja arvo on joukko HTTP-verbejä. match on yleisempi muoto eräistä yleisemmin käytetyistä HTTP-reititysmenetelmistä, kuten get, post ja delete. Se voi vaatia kaikkia samoja vaihtoehtoja kuin nämä menetelmät, mutta verrattuna näihin menetelmiin, se antaa hieman enemmän joustavuutta.
  esimerkiksi käyttämällä match voimme määrittää URL-osoitteen, joka sopii kahdelle eri reitille, joista kukin vastaa kahta eri HTTP-verbiä. Normaalisti tämän tekeminen vaatisi kaksi käskyä yhden sijaan. Voimme nähdä tämän yllä olevasta esimerkistämme, jossa yhdistämme URL-kuvion '/authors/:id' toimintaan 'authors#update'. Määrittelemme sitten, mitä HTTP-verbejä voidaan käyttää pyytämään kyseistä URL-osoitetta via: . Määritä HTTP-menetelmä aina, kun käytät match: ää, sillä voi olla kielteisiä vaikutuksia sovelluksen tietoturvaan.
  match esittää toisen vaihtoehdon reititykselle tiettyihin raiteissa oleviin toimintoihin. Yleensä kannattaa pitäytyä yleisemmin käytetyissä HttpHelpers menetelmissä, kuten get ja post.

• as: mainitsimme hieman aiemmin, että vaihtoehtoa as: voidaan käyttää reittiilmoituksen yhteydessä URL-auttajiemme etuliitteen vaihtamiseen. Tätä voidaan käyttää eri tavoin. Voimme käyttää as:: ää, jotta URL-avustajamme vastaisivat paremmin mukautettuja URL-osoitteita. Toinen käyttö on muuttaa nykyinen URL polku helper jotain enemmän intuitiivinen tai jotain, joka vastaa paremmin resursseja sovelluksen sisällä.

• keräysreitti: Katso, miten edellä peitämme /popular – reittimme posts – resurssin alle. Sen jälkeen määrittelemme on: :collection, minkä osan resurssia alla tämä reitti pesii. Meillä on monia virkoja niin, että pidetään kokoelma. Määrittelemällä on: :collection sanomme: ”Yhdistä URL polkuun /posts/popular.”Jos emme lisänneet on: :collection, Rails olettaa, että tämä reitti vastaa toista resurssia, joka liittyy yhteen viestikokoelmamme jäseneen. Tällöin reitiksi tulisi /posts/:id/popular. Voimme myös määrittää useita keräysreittejä käyttämällä lohkoformaattia.

collection do get 'popular' end 

• ylimääräisen parametrin syöttäminen: voimme määrittää oletusparametrin, joka kulkee aina params hash-tiedostollamme, kun meille täsmätään tiettyjä URL-osoitteita. On olemassa kaksi tapaa täsmentää tämä; yksi tapa on samalla tavalla teemme edellä:

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

popular: true välitetään toimintaamme, että suosittu reitti vastaa via params hash. Sen avain on :popular ja arvo true. Voimme myös käyttää selkeämpää syntaksia syöttämällä hajautuksen reittimenetelmäämme get, jossa avain on defaults: ja arvo on toinen hajautus, joka sisältää sen parametrin nimen, jonka haluamme välittää toiminnallemme.

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

• jäsentie: Voimme käyttää on: member täsmentääksemme, että reittimme sopii yhteen kokoelman jäsenen kanssa. Jos käytämme tätä, dynaaminen segmentti näkyy muodossa :id. Myös URL-apulainen luodaan nimellä preview_post. Täsmentämällä tämän reitin arvolla on: member kerromme Railsille, että kyseessä on tämän tietyn resurssin jäsen. Että se ei ole vain toinen resurssi sisäkkäisiä virkoja, mutta tiiviimmin liittyvät tai liittyvät meidän virkaa tässä sovelluksessa. Useita jäsenreittejä voidaan määritellä lohkoformaatilla;tässä muodossa käytetään samaa syntaksia kuin lohkoformaatissa määriteltäessä useita keräysreittejä, vain korvataan collection luvulla member.

• uudelleenohjaus: on yksi muu käsite puhua, joka näkyy esimerkissämme yllä, ja se on uudelleenohjaus. Rails antaa meille mahdollisuuden ohjata polulta toiselle käyttämällä uudelleenohjausapuria yhdessä reitin kanssa.get '/home', to: redirect('/'). Jos joku yrittää käyttää polkua /home, hänet ohjataan välittömästi juuripolulle /. Tämä ei tietenkään rajoitu vain yhteen URL-polkuun, vaan meillä voisi olla myös jotain tällaista: get '/home', to: redirect('/travel').

arvostelu

kiskojen reitit seisovat hakemuksen edessä. Reitti tulkitsee saapuvan HTTP-pyynnön ja:

• vastaa HTTP-verbin ja pyynnön URL-kuvion yhdistelmään perustuvaa pyyntöä,
• kaappaa tietoa URL-osoitteesta, joka on saatavilla params controller-toiminnoissa
• Rails kannustaa kehittäjiä käyttämään levollisia URL-malleja reittejä määritettäessä, käsitteellistämällä resursseja HTTP-verbeillä.
• resources makron avulla voi luoda levollisia reittejä hyvin nopeasti.