Routes en hulpbronnen

basis Routeringsconventies

laten we eens kijken naar onze routes zoals ze nu zijn, met behulp van 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 

een van de belangrijkste inzichten voor Rails conventies is dat data-centric apps (of CRUDy apps) hebben de neiging om zeer vergelijkbare manieren voor het laten van gebruikers interactie met de applicatie, die zijn:

  • een pagina om een lijst van iets
  • iets
  • een formulier tonen om een nieuwe instantie van iets te maken
  • daadwerkelijk iets aanmaken
  • een formulier tonen om een instantie van iets
  • daadwerkelijk iets bijwerken
  • iets verwijderen

deze zeven “interactiepatronen” zijn zo gewoon, dat Rails een sterke set van conventies van routering naar controllers, weergaven en formulieren om deze workflows eenvoudiger te maken. We gaan ons nu concentreren op het routeringsgedeelte.

Voor de routering van het verdrag is dat in plaats van ons te hebben om te komen met de URL-patronen, Rails beveelt aan dat we de structuur van de Url ‘ s en bijbehorende controller acties op de volgende manier:

Workflow HTTP WERKWOORD PAD Controller Actie
Toon een lijst van berichten GET /berichten berichten#index
Toon een bericht GET /posts/:id berichten#toon
Toon de pagina te maken post GET /berichten/nieuw berichten#nieuwe
een post Creëren POST /berichten berichten#creëer
Toon de pagina voor het bewerken van een bericht GET /posts/:id/bewerken berichten#wijzig
Update een post ZET/PATCH /posts/:id berichten#update
Het verwijderen van een bericht VERWIJDEREN /posts/:id berichten#vernietigen

We kunnen de post deel van onze huidige routing te volgen dit verdrag:

# 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 

En in de routes.rb bestand,

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 

Merk op dat met dit nieuwe patroon, is er een stuk minder werkwoorden in de URL zelf, maar we vertrouwen op de HTTP-woorden (GET/POST/PUT/PATCH/DELETE) voor de voeding van de semantiek voor anders dezelfde URL-patronen, bijvoorbeeld /posts/:id.

merk op dat PUT tot voor kort werd gebruikt voor het bijwerken van bronnen, toen werd vastgesteld dat PATCH een betere semantische match was voor deze actie. Sindsdien heeft Rails de voorkeur gegeven aan PATCH, maar staat beide werkwoorden toe voor updates.

een andere verandering die we later zullen zien is dat we alle URL ‘ s die gerelateerd zijn aan posts zullen routeren naar een PostsController in plaats van alles in ApplicationControlleraf te handelen. De PostController’s actie namen

  • new
  • index
  • show
  • create
  • edit
  • update
  • destroy

zijn ook conventies die overeenkomen met de 7 interactiepatronen.

Dit is de sterkste set van conventies die Rails oplegt aan u als een applicatie ontwikkelaar. We zullen je vragen om het uit je hoofd te leren. We zullen dit opnieuw tal van keren in het boek om u te helpen dat ook te doen.

Routing voor meerdere bronnen

vaak moeten er meerdere bronnen aanwezig zijn in de URL. Bijvoorbeeld voor onze blog-app wanneer we een route nodig hebben om een reactie te maken, is het erg belangrijk dat we weten op welke post deze reactie is gemaakt.

we doen dit momenteel:

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

de Rails conventie van een URL met meerdere geassocieerde bronnen is om te beginnen met de “bevattende” bron helemaal tot aan de “binnenste” bron. Bijvoorbeeld, onze routes voor opmerkingen zou veranderen in:

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

de semantiek van deze URL ‘ s staat voor: “Maak een opmerking onder een specifiek bericht” en “verwijder een opmerking onder een specifiek bericht”. De laatste route, “Toon alle opmerkingen in het systeem”, hoeft niet te worden “scoped” onder een bericht, dus de URL hoeft niet te leiden met “/berichten”.

als we meerdere bronnen in de URL met hun ID ‘ s moeten hebben, is de conventie van dien aard dat de laatste bron de plaatshouder :id zal gebruiken en de rest :resource_id zal zijn, zoals :post_id.

Restful

REST staat voor “Representational State Transfer”. Het is een softwarearchitectuurstijl en richtlijn om schaalbare webservices te maken. REST, als een manier om webapplicaties te structureren, heeft vele facetten, maar laten we eens kijken hoe het van toepassing is op de interface die we gebruiken om te interageren met webapps, de URL ‘ s.

om te zien hoe REST de semantiek van URL ‘ s vereenvoudigt, laten we een voorbeeld doornemen. Laten we zeggen dat we een online pizza besteldienst bouwen. Een naïeve implementatie van de interfaces van de dienst (URL’ s) zou zijn:

/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 

een RESTful interface ontwerp zou er zo uitzien:

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

u kunt zien, RESTful interfaces centreren rond “zelfstandige naamwoorden” of “resources”, het verwijderen van “werkwoorden” van de interfaces, maar in plaats daarvan vertrouwen op de gestandaardiseerde HTTP-werkwoorden (GET/POST/PUT/DELETE) om CRUD semantiek te leveren voor de acties. Werkwoorden zoals check, place, cancel worden direct toegewezen aan HTTP-werkwoorden van GET om op te halen, POST om aan te maken, en DELETE om resource orderte vernietigen. pay en expedite zijn gestructureerd als het aanmaken (HTTP POST) van subbronnen van payments en expeditions onder bron orders.

RESTful interfaces gestandaardiseerde interactiepatronen voor webapplicaties om ze gemakkelijker te begrijpen en te programmeren. Omdat de interfaces zijn gecentreerd rond het manipuleren van bronnen, zijn de reacties veel voorspelbaarder. Een analogie van hoe de RESTful architectuur patroon vereenvoudigt interactie met web services zou zijn hoe de relationele Database en SQL taal vereenvoudigt gegevensopslag. Voordat relationele Database en SQL, gegevens werden meestal opgeslagen in propriëtaire systemen met specifieke logica om te communiceren met hen, dit betekende dat op elk project je zou moeten een andere set van instructies om te communiceren met gegevens te leren. Relationele Databases en SQL gaven een gemeenschappelijke gegevensstructuur (gegevensrecords als rijen en kolommen opgeslagen in tabellen) en een set van gemeenschappelijke interfaces-vier eenvoudige werkwoorden van SELECT, INSERT, UPDATE en DELETE die alle soorten toepassingen kunnen ondersteunen.

het gebruik van een RESTful interface voor uw web app zal ook uw applicatie stroomlijnen om af te stemmen op de manier waarop de backend gegevens worden opgeslagen in databases, en maakt de ontwikkeling gemakkelijker. Dat zien we in de volgende hoofdstukken.

Bronnotatie

we hebben het gehad over Routeringsconventies van Rails en RESTful URL-patronen. Nu zou ons routes.rb bestand er als volgt uitzien:

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

in feite zijn de routes zoals die we hebben in de posts sectie heel gebruikelijk, dus Rails biedt een speciale resources notatie die helpt deze voor u te genereren.

we kunnen gewoon:

resources :posts 

deze lijn zal automatisch de 8 lijnen genereren die we eerder hadden. Merk op dat Voor de update actie, Rails staat zowel PUT en PATCH werkwoord, om compatibiliteitsredenen.

u kunt bundle exec rake routes uitvoeren in uw opdrachtregelomgeving om te controleren of het exact dezelfde set routes genereert.

merk op dat deze enkele lijn 8 routes zal genereren. In ons geval hebben we alle routes hier nodig, maar als je slechts een deel van de routes nodig hebt, kun je ze explicieter definiëren als:

resources :posts, only: 

deze regel hierboven genereert slechts 3 routes voor u-typ bundle exec rake routes om het uit te checken.

geneste bronnen

met Rails kunnen we ook bronnen nestelen om URL-patronen te maken met meerdere bronnen, zie hieronder:

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

voer bundle exec rake routes uit en zie de uitvoer-het zou hetzelfde moeten zijn als wat we eerder hadden.

pad Helpers

wanneer u bundle exec rake routes uitvoert, let dan op de kolom Prefix voor sommige van deze routes. Deze zijn hier om ons te helpen weten hoe we Rails’ aangeboden pad helpers te gebruiken voor onze routes. We kunnen deze voorvoegsels gevolgd door _path gebruiken in onze controllers en weergaven om gemakkelijk paden te bouwen.

bijvoorbeeld:

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

Wat is het voordeel van het gebruik van URL helpers, in plaats van het hard coderen van de paden zoals /posts/123/comments direct in uw code? (bijvoorbeeld, in uw controller actie?) De reden dat u pad helpers wilt gebruiken is dat als u de URL patronen in uw app wilt wijzigen, het een stuk gemakkelijker is om de URL helpers te gebruiken om een ander pad terug te keren-laten we eens kijken naar een voorbeeld:

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

als we de “as” – clausule toevoegen aan deze route, als je bundle exec rake routes uitvoert, zie je de kolom Prefix met register, en je kunt register_path gebruiken om /register het pad te krijgen. Als we nu het pad naar /login willen veranderen, hoeven we alleen maar:

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

nu geeft onze register_path ons /login. We hoeven onze code in de Rails app helemaal niet te veranderen.

meer Routing Conventions

voordat we verder gaan, laten we een snelle blik op een paar variaties van wat we al hebben gezien, evenals een aantal andere functies die beschikbaar zijn voor ons in Rails routing:

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

laten we alle bovenstaande functies één voor één afbreken.

  • root: root wordt gebruikt om aan te geven welke actie wordt toegewezen aan “/”(de URL op het hoogste niveau van onze site die geen pad heeft).De root-URL van uw website / app wordt het meest gebruikt, daarom moet root bovenaan het routebestand worden opgegeven.

  • match + via: match wordt gebruikt om URL-patronen te matchen met een of meer routes. We kunnen ook specificeren welk HTTP-werkwoord gebruikt mag worden voor het matchen met een URL met dit patroon. We doen dit door een hash door te geven aan de match methode. De sleutel voor deze hash is via, en de waarde is een array van HTTP-werkwoorden. match is een meer algemene vorm van een aantal meer gebruikte HTTP-routeringsmethoden, zoals get, post en delete. Het kan allemaal dezelfde opties als die methoden te nemen, maar, in vergelijking met die methoden, het geeft een beetje meer flexibiliteit.
    bijvoorbeeld, door match te gebruiken kunnen we een URL opgeven die overeenkomt met twee verschillende routes, elk overeenkomend met twee verschillende HTTP-werkwoorden. Normaal gesproken zou dit twee commando ‘ s vereisen, in plaats van één. We kunnen dit zien aan ons voorbeeld hierboven, waar we het URL-patroon '/authors/:id' matchen met de actie 'authors#update'. We specificeren vervolgens welke HTTP-werkwoorden gebruikt mogen worden om de aanvraag voor die URL met via: uit te geven. Geef altijd een HTTP-methode op als u match gebruikt, dit kan negatieve gevolgen hebben voor de beveiliging van uw toepassing.
    match biedt een andere optie voor het routeren naar bepaalde acties in Rails. In het algemeen is het het beste gebruik te maken van de meer algemeen gebruikte HttpHelpers methoden, zoals get en post.

  • as: we hebben iets eerder gezegd dat de optie as: kan worden gebruikt met onze route declaratie om het voorvoegsel voor onze URL helpers te wijzigen. Dit kan op verschillende manieren worden gebruikt. We kunnen as: gebruiken om onze URL-helpers beter te laten overeenkomen met aangepaste URL ‘ s. Een ander gebruik is om de huidige URL pad helper te veranderen naar iets meer intuïtief of iets dat beter overeenkomt met de middelen binnen een toepassing.

  • verzamelroute: zie hierboven hoe we onze /popular route nestelen onder de posts bron. Vervolgens gebruiken we on: :collection om aan te geven onder welk deel van een bron we deze route nestelen. We hebben veel berichten dus dat wordt beschouwd als een verzameling. Door on: :collection op te geven zeggen we: “Match een URL met pad /posts/popular.”Als we on: :collection niet hebben toegevoegd, zullen Rails ervan uitgaan dat deze route overeenkomt met een andere bron die is gekoppeld aan een enkel lid van onze posts collectie. In dat geval wordt onze route /posts/:id/popular. We kunnen ook meerdere collectieroutes opgeven met behulp van een blokformaat.

collection do get 'popular' end 
  • een extra parameter doorgeven: we kunnen een standaard parameter opgeven die altijd wordt doorgegeven met onze params hash wanneer we worden gekoppeld aan bepaalde URL ‘ s. Er zijn twee manieren om dit te specificeren; een manier is dezelfde manier als hierboven:
get 'popular', on: :collection, action: :index, popular: true 

popular: true wordt doorgegeven aan onze actie waarmee de populaire route overeenkomt via de hash params. Het heeft een sleutel van :popular en een waarde van true. We kunnen ook meer expliciete syntaxis gebruiken door een hash door te geven aan onze route methode get, waar de sleutel defaults: is en de waarde een andere hash is die de naam bevat van de parameter die we aan onze actie willen doorgeven.

get 'popular', on: :collection, action: :index, defaults: { popular: true} 
  • ledenroute: we kunnen on: member gebruiken om aan te geven dat onze route overeenkomt met een lid van een verzameling. Als we dit gebruiken zal het dynamische segment verschijnen als :id. Een URL-helper zal ook worden aangemaakt als preview_post. Door deze route met on: member te specificeren, vertellen we Rails dat dit een lid is van deze specifieke bron. Dat het niet gewoon een andere bron genest onder berichten, maar nauwer verbonden of gerelateerd aan onze berichten in deze applicatie. Meerdere member routes kunnen worden gedefinieerd met behulp van een blok formaat; dit formaat gebruikt dezelfde syntaxis als het blok formaat voor het definiëren van meerdere collection routes, vervang gewoon collection door member.

  • redirect: er is een ander concept om over te praten dat wordt weergegeven in ons voorbeeld hierboven, en dat is omleiding. Rails geeft ons de mogelijkheid om van het ene pad naar het andere door gebruik te maken van een redirect helper in combinatie met een route.get '/home', to: redirect('/'). Als iemand probeert toegang te krijgen tot het pad /home, zal hij onmiddellijk worden omgeleid naar het root pad /. Dit is natuurlijk niet beperkt tot slechts één URL-Pad; we zouden ook zoiets als dit kunnen hebben: get '/home', to: redirect('/travel').

beoordeling

spoorlijnen staan vooraan bij een aanvraag. Een route interpreteert een inkomend HTTP-verzoek en:

  • komt overeen met een verzoek aan een controlleractie gebaseerd op de combinatie van een HTTP-werkwoord en het verzoek-URL-patroon
  • vangt gegevens op in de URL die beschikbaar moet zijn in params in controlleracties
  • Rails moedigt ontwikkelaars aan om RESTful URL-patronen te gebruiken bij het opzetten van routes, met conceptualisatie van het manipuleren van bronnen met HTTP-werkwoorden.
  • u kunt de macro resources gebruiken om zeer snel RESTful routes te genereren.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.