Почему мне нужно больше работать, чтобы приложение Rails вписалось в архитектуру RESTful?

Question

Я недавно начал проект Rails и решил использовать контроллеры RESTful. Я создал контроллеры для своих ключевых объектов (таких как Страна) и добавил index, new, edit, create, show, update и delete. Я добавил свой map.resources :country в мой файл маршрутов, и жизнь была хорошей.

После того, как разработка немного продвинулась, у меня начались проблемы. Мне иногда требовались дополнительные действия в моем контроллере. Сначала было действие search, которое возвращало опции для моего модного окна автозаполнения поиска. Затем возникла необходимость отображать страны двумя разными способами в разных местах приложения (отображаемые данные тоже были разными, поэтому это были не просто два представления) - я добавил действие index_full. Затем я хотел показать страну по имени в URL, а не по идентификатору, поэтому я добавил действие show_by_name.

Что вы делаете, когда вам нужны действия вне стандартных index, new, edit, create, show, update, delete в RESTful-контроллере в Rails? Нужно ли добавлять (и поддерживать) ручные маршруты в файле rout.rb (что является болью), они идут в другом контроллере, я становлюсь безрезультатным или я пропускаю что-то фундаментальное?

Наверное, я спрашиваю: нужно ли работать усерднее и добавлять действия в мой файл rout.rb для привилегии RESTful? Если бы я не использовал map.resources для добавления вкусностей REST, стандартные маршруты :controller/:action, :controller/:action/:id обрабатывали бы почти все автоматически.

Answer 1

Я бы отнес search как особый случай index. Оба действия возвращают коллекцию ресурсов. Параметры запроса должны указывать такие параметры, как страница, лимит, порядок сортировки и поисковый запрос.

Например:

/resources/index # normal index
/resources/index?query=foo # search for 'foo'

А в resources_controller:

before_filter :do_some_preprocessing_on_parameters

def index
  @resources = Resource.find_by_param(@preprocessed_params)
end

Что касается index_full и search_by_name, вы можете посмотреть, как разделить текущий контроллер на две части. От того, что вы описали, есть запах.

Сказав это, вы абсолютно правы, что нет смысла заставлять ваше приложение использовать спокойные маршруты пользователя, когда оно не доставляет ничего сверх /:controller/:action/:id. Чтобы принять решение, посмотрите, как часто вы используете помощников маршрутизации остальных ресурсов в формах и ссылках. Если вы их не используете, я бы не стал этим заниматься.

Answer 2

Если я выйду за рамки стандартных действий CRUD с моими моделями, я обычно просто добавляю методы по мере необходимости. Поиск - это то, что я добавляю ко многим контроллерам, но не ко всем, поэтому я добавляю его и обычно поддерживаю маршруты:

map.resources :events, :collection => { :search => :get }

Перемещение этих действий на совершенно отдельный контроллер может сделать некоторые из ваших контроллеров RESTful, но я считаю, что держать их в контексте гораздо полезнее.

Answer 3

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

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

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

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

Answer 4

Я не буду более подробно рассказывать о REST, поскольку думаю, что в этом вопросе дан ответ, однако я немного расскажу о маршруте по умолчанию.

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

Например, могут быть контроллеры, которые вы не хотите, чтобы люди могли видеть в одном приложении:

http://example1.somesite.com/example_2/foo/bar/1

Сравните это с

/:controller/:action/:id

Это будет идти к контроллеру example_2 / foo, панели действий и id 1

Я считаю, что это основной недостаток маршрута по умолчанию в Rails, и это то, что RESTful-маршруты (с расширениями поддоменов) или только именованные маршруты (map.connect 'foo' ...) могут исправить.

Answer 5

По-моему, они могли немного сойти с рельсов здесь. Что случилось с СУХОЙ?

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

Answer 6

Чтобы оставаться RESTful в своем дизайне, вам нужно переосмыслить то, что вы называете ресурсом.

В вашем примере действие show для контроллера поиска (ресурс поиска) - это направление, в котором нужно оставаться спокойным.

У меня есть контроллер приборной панели (показать) и контроллеры для отдельных полей встроенных редакторов (показать и обновить)