タグ付けされた質問 「http-method」

まず、いくつかの定義： PUTはセクション9.6 RFC 2616で定義されています。 PUTメソッドは、囲まれたエンティティが指定されたRequest-URIの下に格納されることを要求します。Request-URIが既存のリソースを参照している場合、囲まれたエンティティは、元のサーバーにあるエンティティの変更バージョンと見なされるべきです（SHOULD）。Request-URIが既存のリソースを指さず、そのURIが要求元のユーザーエージェントによって新しいリソースとして定義できる場合、オリジンサーバーはそのURIでリソースを作成できます。 PATCHはRFC 5789で定義されています。 PATCHメソッドは、要求エンティティに記述されている一連の変更を、Request-URIで識別されるリソースに適用するように要求します。 また、RFC 2616セクション9.1.2によれば、PUTはべき等ではなく、PUTはべき等です。 次に、実際の例を見てみましょう。/usersデータを使用してPOSTを実行し、{username: 'skwee357', email: 'skwee357@domain.com'}サーバーがリソースを作成できる場合、サーバーは201とリソースの場所で応答し（仮定/users/1）、次のGET呼び出し/users/1はを返し{id: 1, username: 'skwee357', email: 'skwee357@domain.com'}ます。 次に、メールを変更したいとします。メールの変更は「一連の変更」と見なされるため/users/1、「パッチドキュメント」でパッチを適用する必要があります。私のケースでは、JSON形式のドキュメントのようになります。{email: 'skwee357@newdomain.com'}。その後、サーバーは200を返します（許可に問題がない場合）。これは私に最初の質問をもたらします： パッチはべき等ではありません。RFC 2616とRFC 5789でそう述べられています。ただし、同じPATCHリクエストを（新しいメールで）発行すると、同じリソースの状態が取得されます（メールはリクエストされた値に変更されます）。なぜPATCHはべき等ではないのですか？ PATCHは比較的新しい動詞（2010年3月に導入されたRFC）であり、一連のフィールドの「パッチ」または変更の問題を解決するようになります。PATCHが導入される前は、誰もがPUTを使用してリソースを更新していました。しかし、PATCHが導入された後は、PUTが何に使用されるのか混乱します。そして、これは私に私の2番目の（そして主要な）質問をもたらします： PUTとPATCHの本当の違いは何ですか？特定のリソースの下のエンティティ全体を置き換えるために PUTが使用される可能性があることをどこかで読んだので、（PATCHのような属性のセットの代わりに）エンティティ全体を送信する必要があります。そのような場合の実際の使用法は何ですか？特定のリソースURIにあるエンティティをいつ置換または上書きしますか。また、そのような操作がエンティティの更新/パッチ適用と見なされないのはなぜですか？PUTで私が目にする唯一の実用的な使用例は、コレクションに対してPUTを発行すること、つまり/usersコレクション全体を置き換えることです。PATCHが導入された後、特定のエンティティでPUTを発行しても意味がありません。私が間違っている？

680 json  rest  http  put  http-method 

次のシナリオに適した方法で残りのエンドポイントを設計したいと思います。 グループがあります。各グループにはステータスがあります。グループは、管理者がアクティブ化または非アクティブ化できます。 エンドポイントを次のように設計する必要がありますか PUT /groups/api/v1/groups/{group id}/status/activate または PATCH /groups/api/v1/groups/{group id} with request body like {action:activate|deactivate}

274 http  rest  http-put  http-method  http-patch 

GETまたはPOSTメソッドを使用する場合の違いは何ですか？どちらがより安全ですか？それぞれの（不都合な）利点は何ですか？ （同様の質問）

249 forms  http  post  get  http-method 

RESTfulスタイルのプログラミングでは、ビルディングブロックとしてHTTPメソッドを使用する必要があります。どのメソッドが従来のCRUDメソッドと一致するかについては、少し混乱しています。GET / ReadとDELETE / Deleteは明白です。 ただし、PUT / POSTの違いは何ですか？それらは、作成と更新と1対1で一致しますか？

213 http  rest  crud  http-method 

Curlは、Xで始まる一連の異なるhttpメソッド呼び出しを提供しますが、同じメソッドを提供します。私は両方を試しましたが、違いを理解することができません。これらの2つの操作の違いを誰かがすぐに説明できますか？

126 curl  http-method 

一方でHTTP 1.1仕様は、ように見えることを可能にメッセージ本文をDELETE要求、それのための定義された意味がないので、サーバはそれを無視すべきであることを示していると思われます。 4.3メッセージ本文 サーバーはどんなリクエストでもメッセージ本文を読んで転送すべきです。リクエストメソッドにエンティティボディの定義されたセマンティクスが含まれていない場合、リクエストを処理するときにメッセージボディを無視する必要があります（SHOULD）。 私はすでに、SOやそれ以降のこのトピックに関するいくつかの関連するディスカッションをレビューしました。 エンティティボディはHTTP DELETEリクエストで許可されていますか？ HTTPリクエストメソッドのペイロード リクエストボディを含むHTTP GET ほとんどの議論は、DELETEでメッセージ本文を提供することが許可されている可能性があることに同意しているようですが、一般的には推奨されません。 さらに、さまざまなHTTPクライアントライブラリの傾向に気づきました。DELETEのリクエスト本文をサポートするために、これらのライブラリのログ記録がますます強化されているようです。ほとんどのライブラリは義務的であるようですが、初期の抵抗が少しあることもあります。 私のユースケースでは、DELETEに必要なメタデータを追加する必要があります（たとえば、削除に必要な他のメタデータとともに、削除の「理由」）。私は次のオプションを検討しましたが、HTTP仕様やRESTのベストプラクティス、あるいはその両方と完全に一致しているようには見えません。 メッセージ本文 -仕様は、DELETEのメッセージ本文には意味論的な値がないことを示しています。HTTPクライアントでは完全にはサポートされていません。標準的な練習ではない カスタムHTTPヘッダー -通常、カスタムヘッダーを要求することは標準的な方法に反します。それらの使用は、私のAPIの他の部分と一貫性がなく、いずれもカスタムヘッダーを必要としません。さらに、悪いカスタムヘッダー値を示すために利用できる適切なHTTP応答がありません（おそらく別の質問です） 標準HTTPヘッダー -適切な標準ヘッダーはありません クエリパラメータ - クエリパラメータを追加すると、削除されるRequest-URIが実際に変更されます。標準的な慣行に反して POSTメソッド -（例POST /resourceToDelete { deletemetadata }）POSTは削除のセマンティックオプションではありません。POSTは実際には反対のアクションを表します（つまり、POSTはリソースの下位を作成しますが、リソースを削除する必要があります）。 複数のメソッド -DELETE要求を2つの操作（PUT削除メタデータ、次にDELETEなど）に分割すると、アトミック操作が2つに分割され、一貫性のない状態が残る可能性があります。削除理由（およびその他の関連メタデータ）は、リソース表現自体の一部ではありません。 私の最初の好みはおそらくカスタムHTTPヘッダーの次にメッセージ本文を使用することでしょう。ただし、示されているように、これらのアプローチにはいくつかの欠点があります。 DELETEリクエストにそのような必要なメタデータを含めるためのREST / HTTP標準に沿った推奨事項またはベストプラクティスはありますか？私が考慮していない他の選択肢はありますか？

93 http  rest  httprequest  http-method 

ログインリクエストを行うときに使用するhttpメソッドとその理由を知りたいのですが。このリクエストはサーバー上にオブジェクト（ユーザーセッション）を作成するので、POSTである必要があると思いますが、どう思いますか？しかし、ログイン要求はべき等である必要があるため、PUTで​​ある可能性がありますね。 ログアウトリクエストについても同じ質問ですが、DELETEメソッドを使用する必要がありますか？

93 login  logout  http-method