Понимание "post/redirect/get"

Мне очень трудно понять точный процесс "post/redirect/get". Я прочесал этот сайт и сеть в течение нескольких часов и не могу найти ничего, кроме "вот концепция". Это так просто, что не требует пошагового руководства? Кто-нибудь знает хороший сайт или книгу, которую я мог бы использовать, чтобы найти пример или учебник?

Источник

3 ответа

Решение

Как вы знаете из своего исследования, POST-redirect-GET выглядит так:

  • Клиент получает страницу с формой.
  • Форма POSTс сервером.
  • Сервер выполняет действие, а затем перенаправляет на другую страницу.
  • Клиент следует за редиректом.

Например, скажем, у нас есть такая структура сайта:

  • /posts (показывает список постов и ссылку "добавить пост")
    • /<id> (просмотреть конкретный пост)
    • /create (если запрашивается с GET метод, возвращает форму отправки себе; если это POST запрос, создает сообщение и перенаправляет на /<id> конечная точка)

/posts сам по себе не имеет отношения к этому конкретному шаблону, поэтому я его опущу.

/posts/<id> может быть реализовано так:

  • Найдите сообщение с этим идентификатором в базе данных.
  • Визуализируйте шаблон с содержанием этого поста.

/posts/create может быть реализовано так:

  • Если запрос GET запрос:
    • Показать пустую форму с целью, установленной на себя, и методом, установленным на POST,
  • Если запрос POST запрос:
    • Проверьте поля.
    • Если есть недопустимые поля, покажите форму снова с указанными ошибками.
    • В противном случае, если все поля действительны:
      • Добавьте пост в базу данных.
      • Перенаправить на /posts/<id> (где <id> возвращается из звонка в базу)
Источник

Википедия так хорошо это объясняет!

Эта проблема

Эта проблема

Решение

Решение

Источник

Я постараюсь объяснить это. Может быть, другая точка зрения помогает тебе.

С PRG браузер заканчивает тем, что делает два запроса. Первый запрос является запросом POST и обычно используется для изменения данных. Сервер отвечает с заголовком Location в ответе и без HTML в теле. Это приводит к тому, что браузер будет перенаправлен на новый URL. Затем браузер отправляет запрос GET на новый URL, который отвечает HTML-контентом, который отображает браузер.

Я постараюсь объяснить, почему следует использовать PRG. Метод GET никогда не должен изменять данные. Когда пользователь щелкает ссылку, браузер или прокси-сервер может вернуть кэшированный ответ и не отправлять запрос на сервер; это означает, что данные не были изменены, когда вы хотели, чтобы они были изменены. Кроме того, запрос POST не должен использоваться для возврата данных, потому что если пользователь хочет просто получить свежую копию данных, он вынужден повторно выполнить запрос, что заставит сервер снова изменить данные. Вот почему браузер выдаст вам смутное диалоговое окно с вопросом, уверены ли вы, что хотите повторно отправить запрос и, возможно, изменить данные во второй раз или отправить электронное письмо во второй раз.

PRG представляет собой комбинацию POST и GET, которая использует каждый для того, для чего они предназначены.

Источник

Просто чтобы люди могли увидеть пример кода (используется экспресс):

app.post('/data', function(req, res) {
  data = req.body;  //do stuff with data
  res.redirect('public/db.html');
});

Итак, чтобы уточнить, он мгновенно обновляет веб-страницу, и так при обновлении этой веб-страницы (например, если вы обновили на ней элемент), он не будет повторно размещать данные формы.

Раньше мой код выглядел так:

app.post('/data', function(req, res) {
   data = req.body;
   res.sendFile('public/db.html');
});

Итак, здесь ответ отправляет html-файл по адресу / data. Итак, в адресной строке после нажатия кнопки отправки мне будет сказано:localhost:8080/data. Но это означает, что при обновлении этой страницы, если вы только что отправили форму, она отправит ее снова. И вы не хотите, чтобы одна и та же форма была отправлена ​​дважды в вашу базу данных. Поэтому перенаправление на веб-страницу (res.redirect) вместо отправки файла (res.sendFile) останавливает повторную отправку этой формы.

Источник

Все дело в концепции, больше нечего понимать:

  • POST предназначен для отправки клиентом данных на сервер
  • GET предназначен для того, чтобы клиент запрашивал данные с сервера

Таким образом, концептуально сервер не имеет смысла отвечать данными ресурса на запрос POST, поэтому существует перенаправление на (обычно) тот же ресурс, который был создан / обновлен. Итак, если POST успешен, сервер считает, что клиент хотел бы получить свежие данные, тем самым сообщая ему о необходимости выполнить GET.

Источник
Другие вопросы по тегам