Rotas e parâmetros aninhados para URLs de trilhos (melhores práticas)

Question

Eu tenho um entendimento decente dos URLs repousantes e toda a teoria por trás de URLs de ninho, mas ainda não tenho certeza de como isso parece em um aplicativo corporativo, como algo como Amazon, Stackoverflow ou Google ...

O Google tem URLs como este:

• http://code.google.com/apis/ajax/
• http://code.google.com/apis/maps/documentation/staticmaps/
• https://www.google.com/calendar/render?tab=mc

Amazon assim:

• http://www.amazon.com/books-used-books-textbooks/b/ref=sa_menu_bo0?ie=UTF8&node=283155&pf_rd_p=328655101&pf_rd_s=left-nav-1&pf_rd_t=101&pf_rd_i=507846&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=1PK4ZKN4YWJJ9B86ANC9
• http://www.amazon.com/ruby-programming-language-david-flagan/dp/0596516177/ref=sr_1_1?ie=utf8&s=books&qid=125875625&sr=1-1

E Stackoverflow assim:

• https://stackoverflow.com/users/169992/viatropos
• https://stackoverflow.com/questions/tagged/html
• https://stackoverflow.com/questions/tagged?tagnames=html&sort=newest&Pagesize=15

Então, minha pergunta é: o que é melhor prática em termos de criação de URLs para sistemas como esses? Quando você começa a armazenar parâmetros no URL, quando não é? Essas grandes empresas parecem não estar seguindo as regras tão pouco debatidas na comunidade Ruby (que você quase nunca deveria nidificar URLs, por exemplo), por isso estou me perguntando como você implementa seus próprios URLs em projetos de maior escala, porque ele Parece que a idéia de não aninhar URLs quebra em algo maior que um blog.

Alguma dica?

Answer 1

Não fique muito atolado pelas "regras" na comunidade Ruby. A idéia é que você não exagere ao nidificar os URLs, mas quando forem apropriados, eles são incorporados à estrutura do Rails por um motivo: use -os.

Se um recurso sempre se enquadra em outro recurso, aninhe -o. Nada de errado com isso. Às vezes, é mais profundo do que se pode ser um pouco doloroso, porque seus caminhos de rota serão muito longos e podem ficar um pouco confusos.

Além disso, não confunda o ninho com o nome de nome. Só porque você vê exemplo.com/admin/products/1234/edit não significa que há algum ninho acontecendo. O roteamento pode fazer com que as coisas pareçam aninhadas quando não estão no nível do código.

Pessoalmente, sou um grande fã de nidificação e uso com frequência (apenas um nível - ocasionalmente dois) em minhas aplicações. Além disso, adicionar URLs de estilo Permalink que usam palavras em vez de apenas IDs são mais visualmente atraentes e podem ajudar com o SEO, sejam ou não aninhados.

Answer 2

Acredito que o argumento a favor ou contra o repouso e/ou o ninho em suas rotas tem muito a ver com a forma como você deseja expor sua API. Se você não se importa em expor uma API para seu aplicativo publicamente, há um argumento a ser feito que a estrita adesão ao design RESTful é uma perda de tempo, principalmente se você discordar do raciocínio por trás do descanso. Sua escolha.

Acho que pensar em como um cliente (exceto um navegador) pode acessar informações de seu aplicativo ajuda no processo de design. Uma das maiores vantagens de pensar sobre o design do seu aplicativo da perspectiva da API é que você tende a eliminar a complexidade desnecessária. Para mim, esta é a raiz das precauções que você ouve na comunidade Rails em torno das rotas aninhadas. Eu aceitaria isso como uma indicação de que as coisas estão ficando um pouco complicadas e talvez seja hora de recuar e repensar a abordagem. Os sistemas "maiores que um blog" não precisam ser inerentemente complexos. Algumas partes podem ser, mas você também pode se surpreender quando se aproxima do design de uma perspectiva diferente.

Em suma, considere alguns do dogma que você pode ouvir de certas partes da comunidade como guias e sinais que você pode querer pensar mais profundamente sobre seu design. O descanso rigoroso é simplesmente outra maneira de pensar em como você está estruturando seu aplicativo.

Answer 3

Bem, a primeira coisa a perceber é que, se você olhar para os aplicativos de amostra e código de exemplo, o Rails é bom apenas para criar blogs e carrinhos de compras.

Em seguida, você perceberá que as pessoas que defendem URLs e rotas repousantes sem ninho provavelmente estão apenas construindo blogs e carrinhos de compras.

Eventualmente, haverá iluminação e você aceitará que URLs repousantes e rotas não aninhadas são um monte de besteiras e, em seguida, você poderá criar sua inscrição e fazer o trabalho.