「投稿/リダイレクト/取得」の正確なプロセスを理解するのに非常に苦労しています。
このサイトとウェブを数時間くまなく調べましたが、「ここにコンセプトがあります」以外は何も見つかりません。
post/redirect/get パターンを理解する方法は?
「投稿/リダイレクト/取得」の正確なプロセスを理解するのに非常に苦労しています。
このサイトとウェブを数時間くまなく調べましたが、「ここにコンセプトがあります」以外は何も見つかりません。
post/redirect/get パターンを理解する方法は?
調査からわかるように、POST
-redirect-GET
は次のようになります。
POST
はサーバーに送信されます。たとえば、Web サイトの構造が次のようになっているとします。
/posts
(投稿の一覧と「投稿を追加」へのリンクが表示されます)
/<id>
(特定の投稿を表示)/create
(GET
メソッドでリクエストされた場合、それ自体へのフォーム投稿を返します。リクエストの場合、投稿を作成し、エンドポイントPOST
にリダイレクトします)/<id>
/posts
それ自体は、この特定のパターンとはあまり関係がないので、省略します。
/posts/<id>
次のように実装できます。
/posts/create
次のように実装できます。
GET
:
POST
ます。POST
:
/posts/<id>
(<id>
データベースへの呼び出しから返される場所)説明してみます。たぶん、別の視点があなたのためにトリックを行います.
PRG を使用すると、ブラウザは最終的に 2 つのリクエストを作成します。最初のリクエストは POST リクエストで、通常はデータの変更に使用されます。サーバーは、レスポンスに Location ヘッダーを含めて応答し、本文に HTML は含めません。これにより、ブラウザが新しい URL にリダイレクトされます。次にブラウザは、ブラウザがレンダリングする HTML コンテンツで応答する新しい URL に対して GET リクエストを行います。
PRG を使用する理由を説明します。GET メソッドがデータを変更することは想定されていません。ユーザーがリンクをクリックすると、ブラウザまたはプロキシ サーバーはキャッシュされた応答を返し、要求をサーバーに送信しない場合があります。これは、変更したいときにデータが変更されなかったことを意味します。また、データを返すために POST リクエストを使用しないでください。ユーザーがデータの新しいコピーを取得したい場合は、リクエストを再実行する必要があり、サーバーがデータを再度変更することになります。これが、ブラウザが、リクエストを再送信してデータをもう一度変更するか、電子メールをもう一度送信するかを確認するあいまいなダイアログを表示する理由です。
PRG は POST と GET を組み合わせたもので、それぞれを目的に合わせて使用します。