Rotas e Recursos

Básicos de Roteamento e Convenções

Vamos dar uma olhada em nossas rotas como eles estão agora, usando 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 

Um dos principais insights para Trilhos de convenções é que os dados centrados em aplicativos (ou CRUDy apps) tendem a ter formas muito semelhantes para permitir que os usuários interagem com o aplicativo, que são:

• uma página para exibir uma lista de alguma coisa
• ver algo
• mostrar um formulário para criar uma nova instância de algo
• realmente criar algo
• mostrar um formulário para editar um exemplo de algo
• atualizar, na verdade, algo
• apagar algo

Os sete “padrões de interação” são tão comuns, que o Rails fornece um poderoso conjunto de convenções do encaminhamento para controladores, pontos de vista e formas para ajudar a tornar os fluxos de trabalho mais simples. Vamos concentrar-nos na parte do encaminhamento.

Para o encaminhamento, a convenção é que, em vez de a gente ter que vir para cima com os padrões de URL, Trilhos recomenda que temos a estrutura de URLs e correspondentes ações do controlador da seguinte forma:

Fluxo de trabalho	HTTP VERBO	CAMINHO	Controlador de Ação
Mostrar uma lista de posts	GET	/posts	posts#índice
Mostrar um post	GET	/posts/:id	posts#show
Mostrar a página para criar post	GET	/posts/novo	posts#nova
Criar um post	POST	/posts	posts#criar
Mostrar a página para editar um post	GET	/posts/:id/editar	posts#editar
Atualizar um post	PUT/PATCH	/posts/:id	posts#actualização
Excluir um post	APAGAR	/posts/:id	posts#destruir

Nós pode alterar o post parte de nossa atual de encaminhamento para seguir essa convenção:

# 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 

E no routes.rb arquivo,

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 

Observe que com este novo padrão, há muito menos verbos na própria URL, mas estamos contando sobre os verbos de HTTP (GET/POST/PUT/PATCH/DELETE) para fornecer a semântica para o contrário mesmos padrões de URL, por exemplo, /posts/:id.

Note que PUT tinha sido usado para atualizar os recursos até recentemente, quando PATCH foi determinado a ser um melhor jogo semântico para esta ação. Desde então, Rails passou a preferir PATCH, mas permitindo ambos os verbos para atualizações.

outra mudança que veremos mais tarde é que estaremos encaminhando todos os URLs relacionados com posts para um PostsController em vez de lidar com tudo em ApplicationController. O PostController‘s nomes de ação

• novo
• índice
• mostrar
• criar
• editar
• atualizar
• destruir

também são convenções correspondente a 7 de padrões de interação.Este é o mais forte conjunto de convenções que Rails impõe a você como desenvolvedor de aplicações. Vamos pedir-lhe para fazer um esforço para memorizá-lo. Vamos rever isto muitas vezes ao longo do livro para ajudá-lo a fazer isso também.

roteamento para múltiplos recursos

muitas vezes precisamos ter vários recursos presentes na URL. Por exemplo, para o nosso aplicativo blog sempre que precisamos de ter uma rota para criar um comentário, é muito importante que saibamos em que postar este comentário é criado.Estamos a fazer isto.:

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

A Convenção de Rails de um URL com vários recursos associados é começar com o recurso “contendo” todo o caminho para o recurso “mais íntimo”. Por exemplo, nossas rotas para Comentários mudariam para:

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

a semântica desses URLs representam: “criar um comentário sob um post específico”e” excluir um comentário sob um post específico”. A última rota, “show all comments in the system”, não precisa ser “scoped” sob um post, de modo que a URL não tem que levar com “/posts”.

se precisarmos de ter vários recursos na URL com seus IDs, A Convenção é tal que o último recurso irá usar o espaço reservado :id e todo o resto será :resource_idtal como :post_id.

Restful

REST significa “transferência de Estado representacional”. É um estilo de arquitetura de software e diretriz para criar serviços web escaláveis. O descanso, como forma de estruturar aplicações web, tem muitas facetas, mas vamos apenas olhar como ele se aplica à interface que usamos para interagir com aplicativos web, os URLs.Para ver como o descanso simplifica a semântica dos URLs, passemos por um exemplo. Digamos que estamos a construir um serviço online de encomenda de pizzas. Ingênua de implementação das interfaces do serviço (URLs) seria:

/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 

Uma interface RESTful design seria semelhante a este:

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

Você pode ver, interfaces RESTful centro em torno do “substantivos” ou “recursos”, a eliminação de “verbos” a partir das interfaces, mas em vez de confiar no padronizados verbos de HTTP (GET/POST/PUT/DELETE) para o fornecimento de CRUD semântica para as ações. Verbos como check, place, cancel são mapeados diretamente para os verbos de HTTP de GET para recuperar, POST para criar e DELETE para destruir recurso order. pay e expedite estão estruturados como criação (POST HTTP) de sub recursos de payments e expeditions no recurso orders.

interfaces RESTful padrões padronizados de interação de aplicações web para torná-los mais fáceis de entender e programa contra. Como as interfaces são centradas em torno da manipulação de recursos, as respostas são muito mais previsíveis. Uma analogia de como o padrão de arquitetura repousante simplifica a interação com serviços web seria como o banco de dados relacional e a linguagem SQL simplificam o armazenamento de dados. Antes do banco de dados relacional e SQL, os dados eram normalmente armazenados em sistemas proprietários com lógica específica para interagir com eles, o que significava que em cada projeto você teria que aprender um conjunto diferente de instruções para interagir com os dados. Bancos de dados relacionais e SQL deu em comum uma estrutura de dados (registros de dados como linhas e colunas armazenadas em tabelas) e um conjunto de interfaces comuns – quatro simples e verbos de SELECT, INSERT, UPDATE e DELETE que pode suportar todos os tipos de aplicações.

adoptar uma interface repousante para o seu aplicativo web também irá racionalizar a sua aplicação para se alinhar com a forma como os dados da infra-estrutura são armazenados em bases de dados, e torna o desenvolvimento mais fácil. Veremos isso nos capítulos seguintes.

notação de recursos

temos falado sobre as Convenções de roteamento de Rails, e padrões de URL repousantes. Agora o nosso ficheiro routes.rb pareceria o seguinte:

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

na verdade, as rotas como o que temos na seção posts são muito comuns, então Rails fornece uma notação especial resources que ajuda a gerar essas para você.Podemos simplesmente fazer:

resources :posts 

esta linha irá gerar automaticamente as 8 linhas que tínhamos antes. Note que para a ação update, Rails permite tanto o verbo PUT e PATCH, por razões de compatibilidade.

pode executar bundle exec rake routes no seu ambiente da linha de comando para verificar se gera exactamente o mesmo conjunto de rotas.

Note que esta linha única irá gerar 8 rotas. No nosso caso vamos precisar de todas as rotas aqui, mas se você só precisa de um subconjunto de rotas, você pode defini-las de forma mais explícita como:

resources :posts, only: 

Esta linha acima geraria apenas 3 rotas para você – tipo bundle exec rake routes check-out.

recursos aninhados

Rails também nos permite aninhar recursos para criar padrões de URL com vários recursos, Veja abaixo:

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

execute bundle exec rake routes e veja a saída – deve ser a mesma que tínhamos antes.

ajudantes de caminho

quando você executar bundle exec rake routes, observe a coluna Prefix para algumas destas rotas. Estes estão aqui para nos ajudar a saber como usar trilhos ‘ desde ajudantes de caminho para as nossas rotas. Podemos usar esses prefixos seguidos por _path em nossos controladores e vistas para construir caminhos facilmente.

por exemplo:

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

Qual é a vantagem de usar ajudantes de URL, em vez de codificar os caminhos como /posts/123/comments diretamente em seu código? (por exemplo, em sua ação de controle?) O motivo pelo qual você deseja usar o caminho de ajudantes é que se você deseja alterar os padrões de URL em seu aplicativo, é muito mais fácil usar a URL de ajudantes para retornar um caminho diferente – vejamos um exemplo:

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

Quando adicionamos o “como” cláusula para esta rota, se você executar o bundle exec rake routes, você verá o Prefix coluna register, e você pode usar register_path para obter /register o caminho. Agora, se queremos mudar o caminho para /login, tudo o que temos a fazer é apenas para:

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

Agora o nosso register_path dá-nos /login. Não temos de alterar o nosso código na aplicação Rails.

Mais de Roteamento de Convenções

Antes de prosseguirmos, vamos dar uma rápida olhada em algumas variações do que já vimos, bem como alguns outros recursos disponíveis para nós de roteamento no Rails:

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

Vamos quebrar todas as funcionalidades listadas acima, um de cada vez.

• root: root é usado para especificar que ação mapeia para ” / ” (o URL de nível superior do nosso site que não tem Caminho).O URL raiz do seu site/app é o mais comumente usado, por causa disso root deve ser especificado no topo do arquivo de rotas.

• corresponder ao + via: match é usado para corresponder padrões de URL a uma ou mais rotas. Também podemos especificar qual o verbo HTTP que pode ser usado para corresponder a um URL com este padrão. Fazemos isso passando um hash para o método match. A chave para este hash é via, e o valor é um array de verbos HTTP. match é uma forma de uso mais geral de alguns métodos de roteamento HTTP mais comumente usados, tais como get, post, e delete. Pode levar todas as mesmas opções que esses métodos, mas, em comparação com esses métodos, dá um pouco mais de flexibilidade.
  por exemplo, usando match podemos especificar um URL que corresponde a duas rotas diferentes, cada uma correspondendo a dois verbos HTTP diferentes. Normalmente, fazer isso exigiria dois comandos, em vez de um. Podemos ver isto do nosso exemplo acima, onde combinamos o padrão URL '/authors/:id' com a ação 'authors#update'. Em seguida, especificamos quais verbos HTTP podem ser usados para emitir o pedido para essa URL com via: . Especifique sempre um método HTTP ao usar match, não fazê-lo pode ter implicações negativas na segurança da sua aplicação.
  match apresenta outra opção para encaminhamento para certas ações em trilhos. Em geral, é melhor ficar com os métodos mais comumente usados HttpHelpers, tais como get E post.

• como: mencionamos um pouco antes que a opção as: pode ser usada com a nossa Declaração de rota para alterar o prefixo para os nossos ajudantes de URL. Isto pode ser usado de várias maneiras. Podemos usar as: para fazer os nossos ajudantes de URL melhor corresponder URLs personalizados. Outro uso é mudar o auxiliar do caminho de URL atual para algo mais intuitivo ou algo que se encaixe melhor com os recursos dentro de uma aplicação.

• rota de recolha:veja como acima nidificamos a nossa rota /popular sob o recurso posts. Nós então usamos on: :collection para especificar qual parte de um recurso que estamos nidificando esta rota. Temos muitos posts de modo que é considerado uma coleção. Ao especificar on: :collection estamos dizendo, ” combine uma URL com o caminho /posts/popular.”Se não adicionarmos on: :collection, Rails assumirá que esta rota corresponde a outro recurso associado a um único membro da nossa coleção de posts. Nesse caso, a nossa rota tornar-se-ia /posts/:id/popular. Também podemos especificar várias rotas de coleta usando um formato de bloco.

collection do get 'popular' end 

• passando um parâmetro extra: podemos especificar um parâmetro padrão que sempre é passado com o nosso hash params quando somos correspondidos com certos URLs. Há duas maneiras de especificar isso; uma maneira é a mesma maneira que fazemos acima:

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

popular: true será passado para a nossa ação que a rota popular corresponde com a via params hash. Terá uma chave de :popular e um valor de true. Também podemos usar uma sintaxe mais explícita ao passar um hash para o nosso método de rota get, onde a chave é defaults: e o valor é outro hash contendo o nome do parâmetro que queremos passar para a nossa ação.

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

• rota de membro: podemos usar on: member para especificar que a nossa rota corresponde a um membro de uma coleção. Se usarmos isso, o segmento dinâmico aparecerá como :id. Um auxiliar de URL também será criado como preview_post. Ao especificar esta rota com on: member, estamos dizendo A Rails que este é um membro deste recurso particular. Que não é apenas outro recurso aninhado sob posts, mas mais intimamente ligado ou relacionado com nossos posts nesta aplicação. Várias rotas Membros podem ser definidas usando um formato de bloco; Este formato usa a mesma sintaxe que o formato de bloco para definir várias rotas de coleta, apenas substituir collection por member.

• redirecionamento: há um outro conceito para falar sobre isso é mostrado em nosso exemplo acima, e isso é redirecionamento. Rails nos dá a capacidade de redirecionar de um caminho para outro, usando um auxiliar de redirecionamento em conjunto com uma rota.get '/home', to: redirect('/'). Se alguém tentar acessar o caminho /home , ele será imediatamente redirecionado para o caminho raiz /. Isto não se restringe a apenas um caminho URL, é claro; nós também poderíamos ter algo assim: get '/home', to: redirect('/travel').

revisão

as vias dos carris estão à frente de uma aplicação. Uma rota interpreta um pedido de HTTP recebido e:

• corresponde a um pedido para uma acção do controlador baseada na combinação de um verbo HTTP e o padrão URL do pedido
• captura dados no URL a estar disponível em params nas acções do controlador
• Rails incentiva os programadores a usar padrões de URL repousantes ao configurar as rotas, com conceptualização da manipulação de recursos com verbos HTTP.
• pode utilizar a macro resources para gerar rotas repousantes muito rapidamente.