「post / redirect / get」パターンを理解する
「post/redirect/get」の正確なプロセスを理解するのに非常に苦労しています。
私はこのサイトとWebを数時間くまなく調べてきましたが、「これがコンセプトです」以外は何も見つかりません。
Post/redirect/getパターンを理解するには？
research からわかるように、POST- redirect -GETは次のようになります。
- クライアントはフォームのあるページを取得します。
POSTsという形式でサーバーに送信します。- サーバーはアクションを実行してから、別のページにリダイレクトします。
- クライアントはリダイレクトに従います。
たとえば、次のようなウェブサイトの構造があるとします。
/posts（投稿のリストと「投稿を追加」へのリンクを表示します）/<id>（特定の投稿を表示）/create（GETメソッドで要求された場合は、フォームへの投稿を返します。POST要求の場合は、投稿を作成し、/<id>エンドポイントにリダイレクトします）
/posts自体は、この特定のパターンにはあまり関係がないため、省略します。
/posts/<id>は次のように実装できます：
- データベースでそのIDの投稿を検索します。
- その投稿のコンテンツを含むテンプレートをレンダリングします。
/posts/createは次のように実装できます：
- リクエストが
GETリクエストの場合：- ターゲットがそれ自体に設定され、メソッドが
POSTに設定された空のフォームを表示します。
- ターゲットがそれ自体に設定され、メソッドが
- リクエストが
POSTリクエストの場合：- フィールドを検証します。
- 無効なフィールドがある場合は、エラーを示してフォームを再度表示します。
- それ以外の場合、すべてのフィールドが有効な場合：
- データベースに投稿を追加します。
/posts/<id>にリダイレクトします（<id>はデータベースの呼び出しから返されます）
説明してみます。たぶん別の視点があなたのためのトリックを行います。
PRGを使用すると、ブラウザーは2つの要求を作成します。最初のリクエストはPOST=リクエストであり、通常はデータの変更に使用されます。サーバーはレスポンスにLocationヘッダーを使用し、本文にはHTMLを使用しません。これにより、ブラウザが新しいURL次に、ブラウザは、ブラウザがレンダリングするHTMLコンテンツで応答する新しいURLにGETリクエストを送信します。
PRGを使用する理由を説明します。 GETメソッドがデータを変更することは決して想定されていません。ユーザーがリンクをクリックすると、ブラウザまたはプロキシサーバーがキャッシュされた応答を返し、サーバーに要求を送信しない場合があります。これは、データを変更したいときに変更されなかったことを意味します。また、POSTリクエストを使用してデータを返すことはできません。ユーザーがデータの新しいコピーを取得するだけの場合、リクエストを再実行する必要があるため、サーバーがデータを再度変更します。これが、ブラウザーがあいまいなダイアログを表示し、要求を再送信してデータをもう一度変更するか、またはもう一度メールを送信するかを尋ねる理由です。
PRGは、POSTとGETを組み合わせたものであり、GETの使用目的に応じてそれぞれを使用します。
それはすべて概念の問題であり、理解することはこれ以上ありません。
- POSTは、クライアントがサーバーにデータを送信するためのものです。
- GETは、クライアントがサーバーにデータを要求するためのものです。
したがって、概念的には、サーバーがPOSTリクエストのリソースデータで応答することは意味がありません。そのため、作成/更新された（通常）同じリソースへのリダイレクトがあります。 。したがって、POSTが成功した場合、サーバーはクライアントが新しいデータをフェッチすることを望んでいると考え、その結果、GETを実行するように通知します。