Лучший способ справиться с путаницей UX, вызванной неправильным PUT / POST в REST?

Question

Мой стек - Rails, но проблема на самом деле не зависит от фреймворка

Метод REST говорит, что

В порядкечтобы увидеть форму редактирования для существующего пользователя:

GET: users/:id/edit

Чтобы обновить существующего пользователя:

PUT: users/:id

Что это означает для ошибок проверки

Это все разумно, кроме случаев, когда форму не удается проверить.Если форма не проверяет URL-адрес, на котором вы находитесь, это не users/:id/edit URL-адрес, а вместо этого:

users/:id

Это вызывает две проблемы.Один - это навигация, а другой - что происходит, если пользователь обновляет форму:

Свежая форма редактирования:

Та же форма с ошибками - хотя URL и навигация предполагают, что мы где-то отличаемся

Визуально страница теперь сбивает с толку, поскольку навигация и URL предполагают, что пользовательне в форме редактирования, а вместо этого на странице resource#show.

Что видит пользователь, если он обновляет форму теперь - совершенно другая страница

Она также имеетдругие последствия.Если пользователь разочарован и просто хочет сбросить форму, его инстинкт будет обновлять страницу.Если они это сделают, хотя окажутся на странице resource#show, а не на странице resource#edit.

Наивно мы можем перенаправить неверную отправку обратно в resource#edit URL.Если мы сделаем это, хотя мы не сможем (по умолчанию в Rails) показать им ошибки в форме, которую они только что отправили, поскольку они хранятся в памяти.

Возможные решения

Насколько я вижу, есть два способа решения этой проблемы:

1. Когда PUT users/:id не удается проверить: сериализовать объект user и сохранить его в сеансе.Перенаправьте на GET users/:id/edit, а затем отмените сериализацию объекта на следующей странице, чтобы отобразить ошибки - выглядит грязно
2. Измените маршрут так, чтобы PUT перешел на users/:id/edit вместо users/:id - также чувствует себя грязно .

Вопрос

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

Answer 1

Ну, во-первых, это типичное поведение в приложении rails из коробки.

Если кто-то отправит неверную форму, а затем обновит страницу, что должно произойти? В случае, если вы видели и в типичных приложениях rails, мы просто обновляем и (в случае обновления записи), возможно, извлекаем их из пользовательского опыта. ИМО, все в порядке. Обновление иногда ломает сеть:)

Это обычно видно, когда дизайнер хочет изменить стиль «недопустимой» страницы или разработчик просматривает ошибку рендеринга на странице ошибок, исправляет код или CSS, а затем обновляет страницу, возможно, ожидая увидеть страница исправлена, но вместо этого они могут получить ошибку, связанную с тем, что / сантехники не принимают запросы на получение, или они возвращаются на страницу индекса # сантехники.

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

Если вы хотите изменить поведение, вы можете сделать что-то вроде

 class PlumbersController
    def update 
       plumber = Plumber.find(params[:id]) 
       if plumber.update(params[:plumber])
          redirect_to(plumbers_path, :message => "successfully updated!")
       else 
         flash[:plumber_attributes] = params[:plumber]
         redirect_to plumber_edit
       end
    end
    def edit
       @plumber = Plumber.find(params[:id])  
       @plumber.assign_attributes(flash[:plumber]) if flash[:plumber.present?]
    end
  end

ПРИМЕЧАНИЕ: этот код не был проверен. Основная идея заключается в том, чтобы вставить атрибуты сантехника во флэш-память и перенаправить на URL редактирования сантехника.

Тем не менее, поведение, которое вы описываете, является типичным, и единственный способ, которым рельсы могут обойти это, - полагаться на сессию (флэш) для логики приложения, которую он выбирает не делать "из коробки".