6.3.3 Ресурс Users
Наш метод для отображения страницы пользователя будет следовать соглашениям REST архитектуры, одобренной в приложениях Rails. Этот стиль основан на идеях передачи состояния представления определенный и названный ученым Roy Fielding в его докторской диссертации Architectural Styles and the Design of Network-based Software Architectures.24 REST стиль подчеркивает представление данных как ресурсов которые могут быть созданы, показаны, обновлены, или уничтожены—четыре действия, соответствующие четырем фундаментальным операциям POST, GET, PUT, и DELETE определенным стандартом HTTP (Блок 3.1).
Следуя принципам REST, на ресурсы обычно ссылаются, используя имя ресурса и уникальный идентификатор. Что это означает в контексте пользователей—о которых мы теперь думаем, как о ресурсе Users—то, что мы должны показать пользователя с id 1 выдав GET запрос к URL /users/1. Здесь show действие неявно в типе запроса—когда Rails’ функции REST активированы, GET запросы автоматически обрабатываются show действием.
К сожалению, URL /users/1 еще не работает из-за ошибки маршрутизации (Рис. 6.9). Мы можем получить REST-style Users URL на работу, добавив пользователей в качестве ресурса для config/routes.rb, как видно в Листинге 6.26.
config/routes.rb SampleApp::Application.routes.draw do
resources :users
match '/signup', :to => 'users#new'
.
.
.
end
После добавления маршрутов для ресурса Users, URL /users/1 работает отлично (Рис. 6.10).
Вы, возможно, заметили, что Листинг 6.26 удалил строку
get "users/new"
последний раз замеченную в Листинге 5.29. Это потому что одна дополнительная строка ресурса в Листинге 6.26 не просто добавляет работающий /users/1 URL; она обеспечивает наш пример приложения всеми действиями, необходимыми для RESTful (полностью REST) ресурса Users,25 наряду с большим количеством именованных маршрутов (Раздел 5.2.3) для того, чтобы генерировать URL пользователя. Получившееся соответствие URL, действий, и именованных маршрутов показано в Таблице 6.2. (сравните с Таблицей 2.2.) В течение следующих трех глав, мы охватим остальные записи в Таблице 6.2 поскольку мы заполним все действия, необходимые, чтобы сделать Users полностью RESTful ресурсом.
| HTTP запрос | URL | Действие | Именованный маршрут | Назначение |
|---|---|---|---|---|
| GET | /users | index | users_path | страница, показывающая список пользователей |
| GET | /users/1 | show | user_path(1) | страница показывающая пользователя с id 1 |
| GET | /users/new | new | new_user_path | страница для создания нового пользователя (signup) |
| POST | /users | create | users_path | создание нового пользователя |
| GET | /users/1/edit | edit | edit_user_path(1) | страница для редактирования пользователя с id 1 |
| PUT | /users/1 | update | user_path(1) | обновление пользователя с id 1 |
| DELETE | /users/1 | destroy | user_path(1) | удаление пользователя с id 1 |
params в debug
Прежде, чем оставить страницу, показывающую пользователя, мы займем одну минуту, чтобы исследовать отладочную информацию, произведенную Листингом 6.23. Если Вы присмотритесь к Рис. 6.10, то Вы увидите, что он включает полезную информацию об отображаемой странице:26
--- !map:ActiveSupport::HashWithIndifferentAccess
action: show
id: "1"
controller: users
Это YAML27 представление params, которое (как намекает название HashWithIndifferentAccess) в основном хэш. Мы видим, что его контроллер это users, его действие это show, и его id атрибут это "1". Хотя вы будете редко иметь возможность использовать params[:controller] или params[:action], использование params[:id] для вытаскивания id из URL является общепринятой идиомой Rails. В частности, мы использовали код
User.find(params[:id])
в Листинге 6.25 чтобы найти пользователя с id 1. (find метод знает, как преобразовать строку "1" в целое число 1.)
Debug информация часто обеспечивает полезную обратную связь, при разработке приложений Rails, и я предлагаю привыкнуть проверять ее всякий раз, когда Ваше приложение ведет себя не так как ожидалось.
