JavaScript - get と post は単なる規則ですか?

たとえば、get は冪等で安全だと言いますか?これは単なるルールであるということですか? コードを介して get をポストとして使用することもできます (非冪等で安全ではありません)

返信内容:

たとえば、get は冪等で安全だと言いますか?これは単なるルールであるということですか? コードを介して get をポストとして使用することもできます (非冪等で安全ではありません)

かなり多くの回答があり、さまざまな意見があるため、厳密にするためにいくつか調べてみることにしました

最初の結論は、GET と POST のセキュリティと冪等性に関して、これは単なる規約ではなく標準ですが、標準ではセキュリティと冪等性に関する制約はありません

この問題を解決するために、RFC 7231 ドキュメントを掘り出しました。以前の RFC 2616 は、RFC 7230 から RFC7235 までの 6 つのプロトコル記述に置き換えられました。

https://tools.ietf.org/html/r...

本人が気になるセキュリティ方式と冪等方式について

RFC 7231 の第 4.2.1 章と 4.2.2 章では、「安全なメソッド」と「べき等なメソッド」が何であるかを明確に定義しています

それでは、RFCで定義されている標準では、セキュリティ方式の定義は(私なりのゆるい訳です)

定義されたセマンティクスが本質的に読み取り専用である場合、リクエスト メソッドは「安全」であるとみなされます。つまり、安全なメソッドをターゲット リソースに適用した結果、クライアントがオリジン サーバーの状態変化をリクエストせず、期待しない場合です。同様に、安全な方法を合理的に使用すると、オリジンサーバーに損害、財産の損失、または異常な負担が生じることはありません。

リクエスト メソッドは、本質的に読み取り専用である場合、またはクライアントがメソッドをオリジン サーバー リソースに適用し、リクエストの結果の状態が変更されることを期待していない場合、および適切なセキュリティ メソッドを使用している場合に「安全」とみなされます。損害、財産の損失、またはサーバーに異常な負荷を引き起こすことはありません

安全なメソッドのこの定義は、潜在的に有害な動作、完全に読み取り専用ではない動作、または安全なメソッドの呼び出し中に副作用を引き起こす動作を実装に含めることを妨げるものではありません。ただし、重要なのは、クライアントがそうしなかったということです。たとえば、ほとんどのサーバーは、メソッドに関係なく、すべての応答の完了時にログ ファイルにアクセスするためのリクエスト情報を追加します。これは、たとえログ ストレージがいっぱいになる可能性があるとしても安全であると考えられます。同様に、Web 上の広告を選択して開始された安全なリクエストには、広告アカウントに課金されるという副作用が生じることがよくあります。

この安全なメソッドの定義は、結果に悪影響を与える動作、完全に読み取り専用ではない動作、またはその他の副作用を引き起こす動作の実装を妨げるものではありません。しかし重要なことは、(これらの変更が発生した場合に) 顧客レベルからそれが行われるということです。これらの動作はリクエストなしで (つまり、リクエスト時に予期せずに) 発生するため、クライアントは責任を負いません。たとえば、ほとんどのサーバーは各リクエストの後にリクエスト情報をアクセス ログに記録しますが、問題にならない場合もあります。リクエストに関係なく、ロギングの (一見) 安全な動作でもサーバーがクラッシュする可能性があります。同様に、ウェブ上の広告に対する安全なリクエストでも、広告アカウントに副作用、つまり請求が発生することがよくあります

。

この仕様で定義されているリクエストメソッドのうち、GET、HEAD、OPTIONS、および TRACE メソッドは安全であると定義されています。

このリクエストメソッドの定義では、GET、HEAD、OPTIONS、TRACEメソッドは安全であるように定義されています

べき等メソッドの定義は次のとおりです（私自身のゆるい翻訳も添付します）

そのメソッドによる複数の同一のリクエストのサーバーに対する意図された効果が、この仕様で定義されている単一のリクエスト メソッドの効果と同じである場合、そのリクエスト メソッドは「冪等」とみなされます。 、安全なリクエストメソッド

は冪等です。

リクエスト メソッドは、次の状況で冪等であると見なされます: リクエストが複数のリクエストで 1 つのリクエストと同じ効果を生成する場合、定義されたリクエスト メソッドには PUT、DELETE、およびその他の「安全なメソッド」が含まれます。これも冪等です


私の結論は、GET と POST のセキュリティと冪等性に関して、これは単なる規約ではなく標準ですが、標準にはセキュリティと冪等性に関する制約はありません

(言ってるってことはまだ言ってないみたい)

== 急ぎの元の答えは次のとおりです ==

まだ合意のレベルに達していませんが、これはベストプラクティスであると言うべきです

これをやっていないウェブサイトはたくさんあります

しかし、だからといって私たち自身がこのベストプラクティスを実行することを妨げるものではありません

GET POST は単なる慣例ではなく標準です。
規約と標準の違いは、それが強制されるかどうかです。
契約の履行は個人に依存しており、標準のGET POSTはブラウザで忠実に実行されます。
最後に、少なくともブラウザ環境では、GET と POST の間にいくつかの違いがあることがわかります。
例: GET はフォーム データを送信できないため、コード内で GET を完全に使用して POST を置き換えることはできません。

これは一般的なルールであり、本来の定義はこのように使用することですが、他の使用を妨げるようにハードコーディングされているわけではありません。個人の意見に応じて柔軟に使用できます。

はい、私の意見では、現在特に人気のある RESTful は、実際には http プロトコルの実際の実装です

このように書かないと、同僚に笑われます。 。 。

CURD の観点から見ると、GET はクエリでなければならず、POST は追加、削除、変更でなければならないとは誰も規定しません。そんな意味は無い。

はい、それは慣例です。

アプリケーション層 http プロトコルのメソッド (箸、スプーン、フォークを使った食事など)。

これが合意の作り方です。

クライアントサーバーを自分で実装する場合は、もちろんこれらの合意を無視できますが、ドッキングを行って相手が合意を遵守している場合は、合意を遵守しないと通過できません。

これは提唱者であり標準です。悪用は固く禁止されています。 モバイル アプリと Web サイトはどちらもデータ駆動型の上位層アプリケーションであり、通信は http プロトコルに大きく依存しているため、get と post の違いは単なる慣例ではなく標準であることをできる限り理解することをお勧めします。ルール。変更、削除、作成の操作に関しては、get は使用できません。これが最も重要な前提条件です。もっと深く言えば、それはプロフェッショナルの能力の実現です。

たとえば、フロントエンドとバックエンドが状態を保存するために Cookie を使用し、データの追加または変更に get を使用すると、CSRF によって Web サイトが台無しになります = =