Вложенные маршруты и параметры для URL-адресов Rails (лучшая практика)

Question

У меня есть хорошее понимание URL-адресов RESTful и всей теории, лежащей в основе нераспределения URL-адресов, но я все еще не совсем уверен, как это выглядит в корпоративном приложении, Amazon, StackOverflow, или Google ...

Google имеет URLs, как это:

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

Amazon, как это:

• 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-Flanagan/dp/0596516177/ref=sr_1_1?ie=UTF8&s=books&qid=1258755625&sr=1-1

И StackOverflow так:

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

Так что мой вопрос, что лучше практика с точки зрения создания URLs для систем, как это? Когда вы начинаете хранить параметры в URL-адресе, когда нет? Эти крупные компании, похоже, не следуют правилам, которые так горячо обсуждаются в рубиновом сообществе (что вы почти никогда не должны вставлять URL-адреса, например), поэтому мне интересно, как вы собираетесь внедрять свои собственные URL-адреса в проектах большего масштаба, потому что это похоже, идея о том, что не вложенные URL-адреса ломаются ни на что большее, чем на блог.

Любые советы?

Answer 1

Не увязывайте «правила» в сообществе Ruby. Идея заключается в том, что вы не должны переходить на борт при вложении URL-адресов, но когда они подходят, они встроены в структуру Rails по какой-то причине: используйте их.

Если ресурс всегда попадает в другой ресурс, вставьте его. В этом нет ничего плохого. Идя глубже, чем иногда, может быть немного боль, потому что ваши пути маршрута будут очень длинными и могут немного запутываться.

Кроме того, не путайте вложенность с пространством имен. Просто потому, что вы видите example.com/admin/products/1234/edit, это не значит, что происходит какое-то гнездование. Маршрутизация может заставить вещи выглядеть вложенными, когда они на самом деле не находятся на уровне кода.

Я лично являюсь большим поклонником гнездования и часто использую его (всего один уровень - иногда два) в своих приложениях. Кроме того, добавление URL-адресов в стиле постоянных ссылок, которые используют слова, а не только идентификаторы, более визуально привлекательны, и они могут помочь в SEO, независимо от того, являются они или нет.

Answer 2

Ну, первое, что нужно понять, это то, что если вы посмотрите на примеры приложений и пример кода, то Rails будет полезен только для создания блогов и тележек для покупок.

Далее вы поймете, что люди, которые защищают URL-адреса RESTful и маршруты без гнездования, вероятно, только создают блоги и тележки для покупок.

В конце концов будет просветление, и вы согласитесь, что URL-адреса RESTful и не-вложенные маршруты - это кучка дерьма, а затем вы можете фактически создать свое приложение и получить работу.

Answer 3

Я считаю, что аргумент за или против REST и/или вложенность ваших маршрутов имеет много общего с тем, как вы хотите разоблачить свой API. Если вы не хотите публично публиковать API для своего приложения, есть аргумент в пользу того, что строгое соблюдение дизайна RESTful - это пустая трата времени, особенно если вы не согласны с аргументацией REST. Твой выбор.

Я считаю, что думать о том, как клиент (кроме браузера) может получить доступ к информации из вашего приложения, помогает в процессе проектирования. Одно из самых больших преимуществ мышления в дизайне вашего приложения с точки зрения API состоит в том, что вы склонны устранять ненужную сложность. Для меня это корень предостережений, которые вы слышите в сообществе Rails, окружающем вложенные маршруты. Я бы воспринял это как указание на то, что все становится немного сложнее, и настало время отступить и пересмотреть подход. Системы «больше, чем блог» не должны быть сложными. Некоторые части могут быть, но вы также можете быть удивлены, когда подходите к дизайну с другой точки зрения.

Вкратце, рассмотрите некоторые догмы, которые вы можете услышать от определенных частей сообщества в качестве руководства и сигналов, которые вы можете подумать более глубоко о своем дизайне. Строгий REST - это просто еще один способ подумать о том, как вы структурируете свое приложение.