HTTP GET、PUT、DELETE、POST、HEAD を使用する実際の利点は何ですか? それらの動作上の利点 (安全性と冪等性) に注目し、それらの名前を忘れて、必要な動作に応じて GET、PUT、または POST を使用してみませんか?
GET、PUT、および POST のみを使用してはならないのはなぜですか (および HEAD と DELETE をドロップしないでください)。
Gili
質問する
4259 次
14 に答える
22
[REST][1] アプローチでは、POST、GET、PUT、および DELETE を使用して、Web リソースの CRUD ルールを実装します。これは、オブジェクトを Web 上の要求に公開するためのシンプルで整然とした方法です。オーバーヘッドのない Web サービスです。
セマンティックの違いを明確にするためだけに。それぞれの操作はかなり異なります。ポイントは、明確で明確な意味を持つ適切な HTTP メソッドを用意することです。
POST は新しいオブジェクトを作成します。URI にはキーがありません。オブジェクトを定義するメッセージ本文を受け入れます。SQL 挿入。[編集POST がキーを持たない技術的な理由はありませんが、REST 関係者は、POST が CREATE とは異なる意味を持つためには、キーを持たないほうがよいと強く提案しています。]
GET は既存のオブジェクトを取得します。シングルトン GET を実行しているかリスト GET を実行しているかによって、URIにキーが含まれる場合があります。SQL 選択
PUT は既存のオブジェクトを更新します。URI にはキーがあります。オブジェクトを更新するメッセージ本文を受け入れます。SQL の更新。
DELETE は、既存のオブジェクトを削除します。URI にはキーがあります。SQL 削除。
PUT の代わりに POST でレコードを更新できますか? あいまいさを導入することなくではありません。動詞は明確な効果を持つべきです。さらに、POST URI にはキーがありませんが、PUT にはキーが必要です。
私が投稿するとき、私は 201 CREATED を期待しています。私がそれを取得しない場合は、何かが間違っています。同様に、私が PUT するとき、私は 200 OK を期待します。私がそれを取得しない場合は、何かが間違っています。
POST が POST または PUT のいずれかを実行するというあいまいさを主張できると思います。URI は異なる必要があります。関連するメッセージも異なる場合があります。通常、REST の人々は、INSERT と UPDATE が異なる動詞である SQL からヒントを得ています。
レコードが存在しない場合は UPDATE を挿入し、レコードが存在する場合は更新する必要があります。ただし、UPDATE が UPDATE を意味し、更新の失敗が何か問題があることを意味する場合は、より簡単です。INSERT への秘密のフォールバックにより、操作があいまいになります。
RESTful インターフェイスを構築していない場合は、取得と作成/更新に GET と POST のみを使用するのが一般的です。ユーザーがフォームで [送信] をクリックしたときに、POST と PUT を区別するために URI の違いやメッセージ コンテンツの違いがあるのはよくあることです。ただし、POST=create ケースか POST=update ケースかをコードで判断する必要があるため、あまりクリーンではありません。
于 2008-09-29T01:30:17.180 に答える
13
POSTには、安全性や冪等性の保証はありません。これがPUTとDELETEの 1 つの理由ですはどちらも冪等です (つまり、1+N 個の同一の要求は、1 つの要求と同じ最終結果になります)。
PUTは、特定の URI でリソースの状態を設定するために使用され特定の URI のリソースにPOST要求を送信する場合、そのリソース をコンテンツに置き換えてはなりません。せいぜい、それを追加する必要があります。これが、POST がべき等ではない理由です。POSTS を追加する場合、すべてのリクエストがリソースに追加されます (たとえば、新しいメッセージをディスカッション フォーラムに毎回投稿するなど)。
DELETEは、特定の URI のリソースがサーバーから削除されるようにするために使用されます。POSTは、削除要求を送信する場合を除いて、通常は削除に使用しないで繰り返しますが、その場合に POST するリソースの URI は、削除するリソースの URI であってはなりません。POST 先のリソースは、POST されたデータを受け入れて、それ自体に追加したり、コレクションに追加したり、他の方法で処理したりするリソースです。
HEADは、GET リクエストのヘッダーだけに関心があり、実際のコンテンツで帯域幅を浪費したくない場合に使用されます。これはうれしいですね。
于 2008-10-16T18:29:44.123 に答える
5
なぜ POST 以外のものが必要なのですか? データを双方向に流すことができるのに、なぜ GET が必要なのでしょうか? 答えは基本的にあなたの質問と同じです。さまざまな方法の基本的な期待を標準化することで、他のプロセスは何をすべきかをよりよく知ることができます。
たとえば、キャッシング プロキシを介在させると、正しいことを行う可能性が高くなります。
たとえば、HEAD について考えてみましょう。プロキシ サーバーが HEAD の意味を認識している場合、前の GET 要求の結果を処理して、HEAD 要求に対する適切な応答を提供できます。また、POST、PUT、および DELETE をキャッシュしてはならないことがわかります。
于 2008-09-29T01:35:30.287 に答える
3
探していたような答えは誰も投稿していなかったので、自分でまとめてみます。
「RESTfulWebサービス」の第8章のセクション「POSTのオーバーロード」には次のように書かれています。リソース指向のアーキテクチャですが、RESTの制限の少ないルールに準拠しています。」
つまり、POSTを優先してPUT / DELETEを置き換えると、APIが読みにくくなり、PUT/DELETE呼び出しはべき等ではなくなります。
于 2008-10-16T23:50:26.190 に答える
2
一言で：
冪等性
さらにいくつかの言葉で：
GET = 安全 + べき等
PUT = 冪等
DELETE = 冪等
POST = 安全でも冪等でもない
「べき等」とは、何度も何度も実行でき、常にまったく同じことを行うことを意味します。
PUT (更新) または DELETE 要求は何度でも再発行でき、毎回同じ効果がありますが、目的の効果によってリソースが変更されるため、「安全」とは見なされません。
POST リクエストは、リクエストごとに新しいリソースを作成する必要があります。つまり、効果は毎回異なります。したがって、POST は安全または冪等とは見なされません。
GET や HEAD などのメソッドは単なる読み取り操作であるため、'安全' であると同時に冪等であると見なされます。
これは、HTTP トランザクションを解釈するための標準的で一貫した方法を提供するため、実際には非常に重要な概念です。これは、セキュリティ コンテキストで特に役立ちます。
于 2008-10-27T15:19:28.877 に答える
1
すべてのホスティング事業者が PUT、DELETE をサポートしているわけではありません。
私はこの質問をしました.理想的な世界では、すべての動詞があります....
于 2008-09-29T02:18:39.450 に答える
1
HEAD は、特定のサーバーのクロックが何に設定されているかを判断するのに非常に役立ちます (1 秒以内またはネットワーク ラウンドトリップ時間のいずれか大きい方の精度)。Slashdot から Futurama の引用を取得するのにも最適です。
~$ curl -I slashdot.org HTTP/1.1 200 OK 日付: 2008 年 10 月 29 日水曜日 05:35:13 GMT サーバー: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: スラッシュ 2.005001227 X-Fry: ひよこショーです。World's Blankiest Blank というジャンルの番組が好きです。 キャッシュ制御: プライベート プラグマ: プライベート 接続: 閉じる コンテンツ タイプ: テキスト/html; charset=iso-8859-1
cURLの場合-I、HEAD リクエストを実行するためのオプションです。特定のサーバーの現在の日付と時刻を取得するには、次のようにします。
curl -I $server | grep ^Date
于 2008-10-29T05:36:37.180 に答える
0
GET および POST を使用する Web アプリケーションでは、ユーザーがデータを作成、表示、変更、および削除できますが、これらの目的のために最初に作成された HTTP コマンドよりも上のレイヤーで行うことができます。REST の背後にあるアイデアの 1 つは、Web の設計の本来の意図に戻ることです。これにより、CRUD 動詞ごとに特定の HTTP 操作が行われます。
また、HEAD コマンドを使用して、(潜在的に大きな) ファイル ダウンロードのユーザー エクスペリエンスを向上させることができます。HEAD を呼び出して応答がどれくらい大きくなるかを調べてから、GET を呼び出して実際にコンテンツを取得します。
于 2008-10-16T17:54:44.817 に答える
0
実例については、次のリンクを参照してください。また、OPTIONS http メソッドを使用する 1 つの方法も提案していますが、これについてはまだここでは説明していません。
于 2008-10-16T18:04:57.883 に答える
0
シンプルな REST API の再利用を改善/容易にするため、あいまいさを制限します。
于 2008-09-29T02:23:12.747 に答える
0
GET と POST しか使用できませんが、PUT と DELETE がもたらす精度と明確さの一部が失われます。POST は、何でも意味するワイルドカード操作です。PUT と DELETE の動作は非常に明確に定義されています。リソース管理 API について考える場合、GET、PUT、および DELETE は、おそらく必要な機能の 80% から 90% をカバーします。GET と POST に制限すると、API の 40% ～ 60% が不適切に指定された POST を使用してアクセスされます。
于 2008-09-29T02:30:27.597 に答える
0
追加の機能を必要とする WebDAV のような http 拡張機能があります。
于 2008-10-17T00:00:00.133 に答える
-1
初期の Web サーバー戦争が原因である可能性があります。
1996年に書かれた HTTP 1.0 では、GET、HEAD、および POST しかありませんでした。しかし、付録 Dでわかるように、ベンダーは独自のものを追加し始めました。そのため、HTTP の互換性を維持するために、1999 年に HTTP 1.1を作成することを余儀なくされました。
ただし、HTTP/1.0 では、階層プロキシ、キャッシュ、永続的な接続の必要性、または仮想ホストの影響が十分に考慮されていません。さらに、自身を「HTTP/1.0」と呼ぶ不完全に実装されたアプリケーションの急増により、通信する 2 つのアプリケーションが互いの真の機能を判断できるようにするために、プロトコル バージョンの変更が必要になりました。
この仕様は、「HTTP/1.1」と呼ばれるプロトコルを定義しています。このプロトコルには、その機能を確実に実装するために、HTTP/1.0 よりも厳しい要件が含まれています。
于 2008-09-29T02:40:31.787 に答える
-4
GET、PUT、DELETE、および POST は、2 年生が Web ページをいくつかの高尚な原則に還元できると考えていた時代からの名残です。
現在、ほとんどの Web ページは複合エンティティであり、これらの基本的な操作の一部またはすべてが含まれています。たとえば、顧客情報を表示または更新するためのフォームをページに含めることができます。これは、おそらく複数のテーブルにまたがっています。
私は通常、php で $_REQUEST[] を使用しますが、情報がどのように到着したかはあまり気にしません。基礎となる (複数の) パラダイムではなく、効率に基づいて GET または PUT メソッドを使用することを選択します。
于 2008-10-16T18:07:59.860 に答える