Разные страницы управления учетными записями в RESTful дизайне в Rails 3

Question

Как разные страницы управления учетными записями вписываются в дизайн RESTful в Rails 3?

Например, пользователь регистрируется (создать действие) и затем перенаправляется на страницу успешной регистрации (? Действие), где он находитсяпопросили проверить свой адрес электронной почты через URL с помощью токена (отправленного по электронной почте).

Когда они нажимают на ссылку в электронном письме, технически они "обновляют" свою учетную запись как часть процесса проверки, верно?Так что я думаю, что это каким-то образом отобразится на действие «обновление», но действие обновления ожидает запрос PUT.Это верно?Как заставить это работать через электронную почту?

Мне также интересно, как забытый пароль, сброс пароля и т. Д. Также вписываются в дизайн RESTful?Просто пытаюсь обернуть мою голову вокруг этого.

Answer 1

То, что у вас есть дизайн результата, не означает, что вы ДОЛЖНЫ ограничивать себя только глаголами CRUD, которые отображают 1: 1 для получения / публикации / размещения / удаления. Тем не менее, если вы хотите получить действительно RESTful, вы можете начать думать о некоторых из этих вещей как о своих собственных ресурсах. Например, подтверждение пользователя:

• Пользователь подписывается и получает подтверждающее электронное письмо, у вас уже есть все в квадрате RESTfully это выглядит как
• URL подтверждения выглядит так: http://app.com/user_verifications/new?token=foobar (GET)
• Они следуют за URL-адресом и, возможно, получают сообщение «Привет, Дэн, добро пожаловать! Нажмите здесь, чтобы подтвердить свой аккаунт», когда вы отправляете форму на номер http://app.com/user_verifications, чтобы инициировать действие создания там. Теперь на бэкэнде вы можете выполнять любые действия, которые вы хотите, обновляя пользователя, устанавливая его активным или фактически создавая модель UserVerification.

Не идеальный пример, но идея в том, что предоставляемый вами интерфейс RESTful имеет дополнительный ресурс, в данном случае «user_verifications», и пользователь использует его с помощью HTTP-методов для достижения целей пользователя. Вы можете применить аналогичную логику для сброса / забывания пароля либо с ресурсом типа «UserSession», либо даже с указанием конкретного ресурса «ForgotPassword».

Answer 2

1. Успешная страница - это просто create.html.erb файл. Обычно вы перенаправляете из действия создания, но здесь вы можете просто визуализировать шаблон успеха.

2. Проверка. Если вы хотите остаться в REST, вам нужно добавить еще один шаг: GET проверить, где находится форма с вашим токеном, что приведет к действию PUT update. Пользователь получает ссылку на эту страницу.
   
   Но я предпочитаю использовать простой запрос GET, который обновит информацию без каких-либо дополнительных кликов.

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