web-dev-qa-db-ja.com

更新および削除用のHTTPステータスコード

UPDATE（PUT）およびDELETEにはどのようなステータスコードを設定すればよいですか（例：製品は正常に更新されました）。

httphttp-status-codes
1156
xpepermint

_ put _ requestの場合： HTTP 200 または HTTP 204 は、「リソースが正常に更新された」ことを意味します。

_ delete _ requestの場合： HTTP 200 または HTTP 204 は、「リソースが正常に削除された」ことを意味します。 HTTP 202 も返される可能性があります。これは、指示がサーバーによって受け入れられ、「リソースに削除のマークが付けられた」ことを意味します。

9.6 PUT

既存のリソースが変更された場合、リクエストが正常に完了したことを示すために、200（OK）または204（No Content）のレスポンスコード> SHOULDが送信されます。

9.7 DELETE

応答がステータスを記述するエンティティを含む場合は200（OK）、アクションがまだ実行されていない場合は202（承認済み）、アクションが実行されたが応答が含まれない場合は204（コンテンツなし）エンティティ。

出典： w3.org：HTTP/1.1メソッドの定義

HTTP 200 OK： 成功したHTTP要求に対する標準の応答。実際の応答は、使用される要求方法によって異なります。

HTTP 204 No Content： サーバーはリクエストを正常に処理しましたが、コンテンツを返していません。

ソース： HTTPステータスコードのリスト：2xx成功

1787
Daniel Vassallo

簡単な答え：PUTとDELETEの両方に対して、200（OK）か204（No Content）のどちらかを送るべきです。

長い答え：これが完全な意思決定図です（クリックすると拡大されます）。

HTTP 1.1 decision diagram

ソース： https://github.com/for-GET/http-decision-diagram

789
ЯegDwight

ここにいくつかのヒントがあります：

DELETE

  • 200（応答に追加のデータを送信する場合）または204（推奨）。

  • 202削除された操作はまだコミットされていません。

  • 削除するものがない場合は、204 または 404を使用します（DELETE操作は同じです、既に削除されたアイテムの削除は 操作は成功 です。あなたは204を返すことができますが、べき乗は必ずしも同じ応答を意味するわけではないことは事実です）

その他のエラー

  • 400 不正な要求 （不正な構文または不正なクエリーは 奇妙 ですが可能です）。
  • 401 未承認 認証失敗
  • 403 禁止 ：認証失敗または無効なアプリケーションIDです。
  • 405 許可されていません 。もちろんです。
  • 409 リソースの競合 複雑なシステムでは可能性があります。
  • エラーの場合は501、502となります。

PUT

コレクションの要素を更新している場合

  • 上記のDELETEと同じ理由で200/204。
  • 操作がまだコミットされていない場合は202。

参照されている要素は存在しません。

  • PUTは201にすることができます（これがあなたの振る舞いなので要素を作成した場合）

  • 404 PUTで要素を作りたくない場合。

  • 400 不正な要求 （DELETEの場合よりも不正な構文または不正なクエリが多い）。

  • 401 未承認
  • 403 禁止 ：認証失敗または不正なアプリケーションIDです。
  • 405 許可されていません 。もちろんです。
  • 409 リソースの競合 DELETEのように複雑なシステムでも発生する可能性があります。
  • 422 処理不可能なエンティティ 「不正なリクエスト」（不正なXML/JSONなど）と無効なフィールド値を区別するのに役立ちます
  • エラーの場合は501、502となります。
127
Alfonso Tienda

RFC 2616は/について説明します どのステータスコードを使用するか 。

いいえ、それはnot常に200です。

13
Ignacio Vazquez-Abrams

200および204に加えて、 205（コンテンツのリセット） が有効な応答になる可能性があります。

サーバはリクエストを実行し、ユーザエージェントはリクエストを送信させる原因となったドキュメントビューをリセットすべきである[...]入力が与えられたフォームのクリア。

9
pje

質問はif _ delete _ "should" return 200 vs 204 を詳しく調べているので、リンク付きのエンティティを返すことを推奨する人もいます。 200 の場合です。

「204（コンテンツなし）を返す代わりに、APIを使用すると便利です。この例では、提供する明らかなリンクの1つは "'somewhere.com/container/'（マイナス 'リソース'）です。 "））" "クライアントがリソースを削除したばかりのコンテナです。おそらくクライアントはより多くのリソースを削除したいので、それが役に立つリンクになるでしょう。"

http://blog.ploeh.dk/2013/04/30/rest-lesson-learned-avoid-204-responses/ /

クライアントが204応答に遭遇した場合、それはあきらめるか、APIのエントリポイントに行くか、またはそれが訪れた前のリソースに戻ることができます。どちらの選択肢も特に良いものではありません。

個人的には、クライアント側での優れたキャッシュには多くの利点があるので、204は間違っているとは思いません（作者もそうではありません。彼は "いらいら"とも言っています）。どちらの方法でも一貫していることが最善です。

6
KCD

2014年6月に RFC7231 はRFC2616を廃止しました。 HTTP経由でRESTを実行している場合、 RFC7231 はGET、PUT、POSTおよびDELETEから期待される動作を正確に記述します。

2
Ivan

ここにいくつかのステータスコードがあります。これは、あなたの知識のために知っておく必要があります。

1XX情報応答

  • 100続行
  • 101スイッチングプロトコル
  • 102処理中
  • 103アーリーヒント

2XXの成功

  • 200OK
  • 201作成済み
  • 202Accepted
  • 203権限のない情報
  • 204コンテンツなし
  • 205コンテンツのリセット
  • 206部分コンテンツ
  • 207マルチステータス
  • 208報告済み
  • 226IM使用

3XXリダイレクト

  • 300複数の選択肢
  • 301永久に移動
  • 302見つかった
  • 303その他を見る
  • 304変更なし
  • 305プロキシを使用
  • 306プロキシの切り替え
  • 307一時的なリダイレクト
  • 308パーマネントリダイレクト

4XXクライアントエラー

  • 400悪いリクエスト
  • 401無許可
  • 402支払いが必要
  • 403禁止
  • 404見つかりません
  • 405許可されていないメソッド
  • 406受け入れられない
  • 407プロキシ認証が必要
  • 408リクエストのタイムアウト
  • 409競合
  • 410ゴーン
  • 411長さが必要
  • 412前提条件の失敗
  • 413ペイロードが大きすぎる
  • 414RIが長すぎる
  • 415サポートされていないメディアタイプ
  • 416範囲が満足できない
  • 417期待失敗
  • 418私はティーポットです
  • 420メソッドの失敗
  • 421誤ったリクエスト
  • 422処理不能なエンティティ
  • 423ロック済み
  • 424失敗した依存関係
  • 426アップグレードが必要
  • 428前提条件が必要
  • 429リクエストが多すぎる
  • 431リクエストヘッダーフィールドが大きすぎます
  • 451法的理由では利用不可

5XXサーバーエラー

  • 500内部サーバーエラー
  • 501未実装
  • 502悪いゲートウェイ
  • 503サービス利用不可
  • 504ゲートウェイのタイムアウト
  • 505Httpバージョンはサポートされていません
  • 506変数もネゴシエート
  • 507ストレージ不足
  • 508ループ検出
  • 510非拡張
  • 511ネットワーク認証が必要
1
Prince

ハイパーテキスト転送プロトコル（HTTP/1.1）：セマンティクスとコンテンツ

簡単に説明しました！ ステータスコードの詳細

0
Ahamed Rasheed