Как вы обрабатываете все способы, которые вы могли бы отправлять из HTTP POST? - PullRequest
5 голосов
/ 02 июня 2009

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

Если данные действительны и пользователь ожидает HTML, вы хотите выполнить перенаправление, чтобы обновление не вызывало повторную публикацию. Вы хотите перенаправить к рефереру, если он существует, и отобразить сообщение. Если они не ожидают HTML, вы можете просто вернуть 200 OK.

Если данные недействительны и пользователь ожидает html, вы хотите перерисовать страницу, с которой они пришли, с видимой ошибкой, чтобы они могли повторно опубликовать. Для этого вам нужно будет выполнить предыдущее действие и сообщить ему об ошибке. Чтобы решить, каким было предыдущее действие, возможно, вы включили его в качестве скрытого параметра в форме. Если они не ожидают HTML, вы можете вернуть соответствующую ошибку клиента 4xx.

Я слишком много раз исполняю этот глупый танец. Итак, вопросы:

1) Как бы вы абстрагировали весь этот процесс, чтобы любой пост в форме мог им воспользоваться?

2) Какой самый удобный или наименее повторяемый способ добиться этого в вашей любимой веб-среде?

3) Есть ли что-нибудь, что вы могли бы изменить во всем этом процессе, чтобы сделать его проще?

Идея 1: Никогда не визуализировать сообщение, всегда перенаправлять. Заполните данные об ошибках в сеансе за доли секунды между запросами, а затем очистите их, как сообщение об успешном завершении. Таким образом, действительные и недействительные сообщения могут обрабатываться одинаково.

Идея 2: Не делайте никаких обычных сообщений HTTP. Используйте только Ajax. Теперь вам не нужно беспокоиться о рендеринге или перенаправлении. Это будет полезно, только если у вас уже есть ajax-приложение.

Ответы [ 3 ]

3 голосов
/ 02 июня 2009

Идея 2 выходит в окно. Это ужасная идея и совсем не нужна. AJAX хорош, но не переусердствуйте. Не говоря уже о том, что этот кусок пользователей с отключенным Javascript?

Я думаю, что вы думаете (даже не подозревая об этом), это шаблон Post / Redirect / Get . Это лучшая практика, когда дело доходит до этого, и вы должны следовать ей. По сути, как вы сказали, вы никогда не отвечаете на POST чем-либо, кроме перенаправления. Что касается уведомлений, большую часть времени вы знаете , откуда они приходят из-за определенного действия. Если вы этого не сделаете, HTTP REFERER является достойной альтернативой. Да, это можно отключить, но это ~ 1% ваших пользователей, если это так. Что касается уведомлений, сессии идеально подходят для этого. Просто сохраните код и сообщение в текущем сеансе и сообщите о них вашему шаблону. Распечатайте сообщение, если оно существует, и удалите переменные сеанса.

0 голосов
/ 10 октября 2012

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

0 голосов
/ 02 июня 2009

Нет ничего постыдного в выполнении обратных передач, и вы действительно не можете избежать обратных передач, потому что это самый простой способ сохранить данные в HTTP-запросах. Это или параметры запроса, которые представляют собой еще одну обратную передачу на сервер, так что это равносильно тому, что есть несколько компромиссов. Использование состояния просмотра или сеансов не рекомендуется.

В идеале, эта же страница будет проверять, является ли запрос отправкой назад, и обрабатывать всю логику в ней. Поэтому чаще всего ваш код или страницы приложений с формами содержат раздел для обработки возврата. *

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...