Блог

Каковы минусы использования универсального маршрута:

match ':controller(/:action(/:id(.:format)))'

Мне сказали, что это не рекомендуется, но я не понимаю, почему. Какие проблемы я могу получить от использования этого?

Потому что проще реализовать REST, если вы используете противоположный порядок, ':controller(/:id(/:action))' и в rails теперь есть более удобные способы получения правильного HTTP-глагола с использованием явных resource маршрутов.

Понимание основных принципов REST облегчит вам предоставление API, если вы решите пойти по этому маршруту, который охватывает принципы HTTP. Это также, как правило, не позволяет вам выполнять определенные необязательные действия, например, позволяет удалять записи с помощью запроса GET. (Отсутствие уровня может быть обнаружено только до тех пор, пока Google или ваш внутренний поисковый бот не решит проиндексировать все ссылки на :действия удаления.)

Основная идея заключается в том, что GET / URL должен подразумевать выборку ресурса. Когда вы ставите действие первым, ресурс становится полузакрытым, и вы случайно открываете дверь для потенциальных ошибок, потому что все методы HTTP могут использоваться для вызова деструктивных действий. Используя подход, ориентированный на HTTP-глагол, вы можете отправить запрос на ОБНОВЛЕНИЕ по тому же URL, что и запрос на показ.

Конкретный ответ на ваш вопрос, который, как я понимаю, заключается в понимании минусов общего подхода:

Одним из существенных рисков является то, что вы делаете каждое отдельное действие контроллера (незащищенное) доступным для ваших пользователей. Это дает им возможность получить доступ ко всему вашему «дереву» действий контроллера, что может быть или не быть желательным в зависимости от вашей ситуации.

Кроме того, вы даете пользователям возможность ПОЛУЧАТЬ, а не публиковать, размещать, а не ПОЛУЧАТЬ и т.д.

Сгенерированный комментарий над ним довольно хорошо объясняет это.

# Примечание: Этот маршрут сделает все действия в каждом контроллере доступными через запросы GET.

Это означает, что теоретически вы могли бы выполнить запрос GET по маршруту, который должен быть доступен только через POST. ie. Вы могли бы добавить маршрут с именем / postable к пользовательскому объекту, на который следует отправлять только POST’d, но если вы используете приведенное выше правило, вы также можете выполнить для него запрос GET (с пустыми параметрами).

На самом деле у вас не возникает проблем, как таковых. Вместо этого вы теряете преимущества, которые получаете от использования маршрутизации ресурсов:

• Общий шаблон, который помогает упростить дизайн контроллера
• Бесплатная обработка HTTP-глаголов в стиле RESTlike ( GET , PUT , POST , DELETE )
• Мира, любви и счастья*

Вы можете узнать больше о маршрутизации ресурсов, прочитав Руководство по маршрутизации Rails.

^{* Мир, любовь и счастье доступны не во всех областях. Применяются правила и условия.}