При создании веб-системы ввода данных возникает тот факт, что вы добавляете дополнительный запрос на сервер на страницу, представляя серьезную проблему, когда решаете, использовать или не использовать проект post/redirect/get?post/redirect/get
Да, но не просто по соображениям производительности.
Если у вас есть балансировка нагрузки и репликация базы данных, вы должны убедиться, что GET после POST действительно увидит данные, которые были опубликованы, поэтому вам необходимо настроить балансировщик нагрузки, чтобы перенаправить пользователей на ваш «мастер» веб-сайт или точно такой же компьютер, который получил POST (в зависимости от того, как вы реализовали хранилище).
Этот запрос не является проблемой, особенно, что альтернатива дает довольно плохую работу пользователя и может привести к еще более бесхитростным запросам, чем простое перенаправление.
В большинстве случаев сообщения появляются только при изменении данных. Большинство трафика и времени процессора на сайтах генерируются запросами (GETS), а не изменениями, поэтому я считаю, что эти дополнительные запросы не очень значительны.
Если я понимаю ваш вопрос (и я не совсем уверен, что знаю), это определенно хороший дизайн, чтобы сделать перенаправление после публикации, даже если вы показываете им одну и ту же страницу с обновленной информацией.
Выполняя перенаправление, вы нарушаете соединение между просматриваемой страницей и POST, которая вызвала изменение. Пользователь может добавлять закладки и/или обновлять страницу без всплывающего окна с запросом «Повторная отправка данных?»
Можете ли вы привести рабочий пример? –
Я не знаю, какой язык/фреймворк/сервер вы используете, но есть примеры gazillion в сети на любом возможном языке. Просто выполните поиск по POST/REDIRECT/GET. [Здесь находится страница Wikipedia] (https://en.wikipedia.org/wiki/Post/Redirect/Get). –
Я прошел через все такие статьи, но не смог понять еще. Я понимаю здесь: В abc.php
Я думаю, что удобство использования, которое это предлагает, перевешивает небольшой удар производительности.
Проверьте это, выполнив некоторые контрольные показатели производительности, и вы сможете узнать, будет ли это проблемой в вашем конкретном случае. См. this article для получения дополнительной информации.
Другим вариантом является использование зеркального отображения базы данных вместо репликации и memcached для кэширования. Тогда не имеет значения, к какому интерфейсу пользователь перенаправляется. –
Спасибо за дополнительные вещи, о которых стоит подумать! – Wes