Rails: RESTful ресурсы: стоит использовать или негибкие / переоцененные? - PullRequest
Новая
       6

Rails: RESTful ресурсы: стоит использовать или негибкие / переоцененные?

5 голосов
/ 22 ноября 2010

Последние 2 месяца я крутился на рельсах, и пока все идет хорошо, но есть одна область, в которой я немного сомневаюсь.

Я продолжаю слышать о радостях ресурсов RESTful rails: то есть 'resource: foo' в config / routs и ваших 7 restful действиях в контроллере.

За исключением очень простых вещей (например, вещей, которые на 99% выполнены с помощью 'генерации скаффолдов'), я считаю, что менее удобно пытаться втиснуть функциональность моего проекта в этот подход, чем просто сопоставлять URL-адреса в конфигурации / маршрутах по одному один и делать каждое действие по мере необходимости.

Но я продолжаю чувствовать, что я неправ, и что во всех случаях, кроме самых экстремальных, RESTful-ресурсы - это путь.

Итак:

(а) Кто-нибудь может высказать свое мнение по этому поводу?

(b) Для опытных людей, работающих на рельсах, какой% ваших маршрутов в типичном проекте: ресурсы и какой% кодируются «действие за действием»? Приветствия ...

Ответы [ 2 ]

5 голосов
/ 23 ноября 2010

Ресурсы удобны, но они не являются универсальной функцией.Некоторые вещи просто не имеют смысла с 7 методами.

Имейте в виду, что вы можете :

  • Исключить определенные методы с помощью :except.
  • Включите только определенные методы с помощью :only.
  • Добавьте свои собственные методы к ресурсу.

Так что они не так негибки, как вы думаете.Но если, учитывая эти 3 пункта, ресурс просто «не чувствует себя хорошо», пропустите его !REST никогда не предназначался для замены обычной маршрутизации, он просто пытается абстрагироваться от наиболее распространенного варианта использования.

Если вы полностью пропустите ресурсы RESTful, вам не хватит тонны бесплатной функциональности.Используйте это с умом, и все будет в порядке.

0 голосов
/ 23 ноября 2010

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

Вот статья о подходе:

http://ablogaboutcode.com/2010/11/22/to-be-or-not-to-be-restful-ruby-on-rails-best-practices/

Прежде чем начать, вот несколько вопросов, которые вы, возможно, захотите задать себе:

  1. Имеет ли этот контроллер / представление в первую очередь отношение к объекту / сущности, например, Post, Blog?
  2. Создание, обновление, удаление, редактирование и новые действия будут доступны в Интернете?

В качестве руководства, если вы ответите ДА на эти два вопроса, то, вероятно, лучше начать с REST и ожидать, что вы в конечном итоге будете использовать архитектуру в качестве строительного блока для дополнительных действий и представлений, которые вы, возможно, захотите выполнить. В противном случае выберите URL-адрес, который лучше всего показывает, что действие будет показывать или выполнять (/ archives, / tour, / December-offer) и убедитесь, что вы используете правильные HTTP-протоколы (GET для отображения, PUT для обновления, DELETE для удаления и POST для создания).

...