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

UPDATE（PUT）およびDELETE（たとえば、製品が正常に更新された）にはどのステータスコードを設定する必要がありますか？

以下のためのPUT要求：HTTP 200またはHTTP 204を意味するものでなければならない「リソースが正常に更新します」。

以下のためにDELETEリクエスト：HTTP 200またはHTTP 204「リソースが正常に削除」を意味するものでなければなりません。HTTP 202を返すこともできます。これは、命令がサーバーによって受け入れられ、「リソースに削除のマークが付けられた」ことを意味します。

プット

既存のリソースが変更された場合、200（OK）または204（No Content）応答コード>を送信して、リクエストが正常に完了したことを示す必要があります。

削除

成功した応答は、応答にステータスを説明するエンティティが含まれている場合は200（OK）、アクションがまだ実行されていない場合は202（承認済み）、アクションが実行されているが応答に含まれていない場合は204（コンテンツなし）であるべきです（SHOULD）。エンティティ。

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

HTTP 200 OK：成功したHTTPリクエストに対する標準応答。実際の応答は、使用される要求メソッドによって異なります。

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

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

短い答え：PUTとDELETEの両方で、200（OK）または204（コンテンツなし）を送信する必要があります。

長い答え：これは完全な決定図です（クリックして拡大）。

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

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

削除

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

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

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

その他のエラー：

• 400 Bad Request（不正な構文または不正なクエリは奇妙ですが可能です）。
• 401 不正認証の失敗
• 403 Forbidden：承認エラーまたは無効なアプリケーションID。
• 405 許可されない。承知しました。
• 409 リソースの競合は、複雑なシステムで発生する可能性があります。
• および501、502エラーが発生した場合です。

プット

コレクションの要素を更新する場合

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

参照された要素は存在しません：

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

• 404 PUTを介して要素を作成したくない場合。

• 400 Bad Request（不正な構文または不正なクエリがDELETEの場合よりも一般的）。

• 401 無許可
• 403 Forbidden：認証失敗または無効なアプリケーションID。
• 405 許可されない。承知しました。
• 409 リソース競合が DELETEのように、複雑なシステムで可能であることができます。
• 422 Unprocessable entityこれは、「不正なリクエスト」（たとえば、不正なXML / JSON）と無効なフィールド値を区別するのに役立ちます
• および501、502エラーが発生した場合です。

RFC 2616では、使用するステータスコードについて説明しています。

いいえ、常に200になるとは限りません。

200および204に加えて、205（Reset Content）は有効な応答である可能性があります。

サーバーは要求を満たし、ユーザーエージェントは要求を送信する原因となったドキュメントビューをリセットする必要があります... [例]入力が与えられたフォームのクリア。

質問では、DELETEが200と204のどちらを返す必要があるかを詳しく説明しているため、リンク付きのエンティティを返すように推奨する人もいるので、プリファレンスは200に設定することを検討してください。

「204（コンテンツなし）を返す代わりに、APIは役立つはずであり、行くべき場所を提案します。この例では、提供すべき明らかなリンクの1つは、「somewhere.com/container/」（マイナス「リソース」）へのリンクです」-クライアントがリソースを削除したコンテナ。おそらくクライアントはさらにリソースを削除したいので、それが役立つリンクになります。」

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

クライアントが204応答を検出した場合、クライアントはあきらめるか、APIのエントリポイントに移動するか、以前にアクセスしたリソースに戻ることができます。どちらのオプションも特に良いものではありません。

個人的には、204が間違っているとは言いません（著者もそうではありません。彼は "迷惑"と言っています）。クライアント側での適切なキャッシュには多くの利点があるからです。どちらの方法でも一貫性を保つことが最善です。

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

1XX情報応答

• 100 続行
• 101 スイッチングプロトコル
• 102 処理
• 103 初期のヒント

2XX成功

• 200 OK
• 201 作成されました
• 202 受け入れ
• 203信頼でき ない情報
• 204 コンテンツなし
• 205 コンテンツをリセット
• 206 部分的なコンテンツ
• 207 マルチステータス
• 208 報告済み
• 226 IM使用

3XXリダイレクト

• 300 複数の選択肢
• 301 永久に移動
• 302 見つかりました
• 303 他を見る
• 304 変更されていません
• 305 プロキシを使用
• 306 スイッチプロキシ
• 307 一時的なリダイレクト
• 308 永久リダイレクト

4XXクライアントエラー

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

5XXサーバーエラー

• 500 内部サーバーエラー
• 501 実装されていません
• 502 Bad Gateway
• 503 サービスを利用できません
• 504 ゲートウェイタイムアウト
• 505 Httpバージョンはサポートされていません
• 506 Varientまた交渉します
• 507 ストレージ不足
• 508 ループが検出されました
• 510 拡張されていません
• 511 ネットワーク認証が必要です

2014年6月にRFC7231はRFC2616を廃止しました。REST over HTTPを実行している場合、RFC7231は、GET、PUT、POST、DELETEから予想される動作を正確に説明しています

リソースが変更されると、応答コードは200（「OK」）になります。リソースのURIを変更するようにリソースの状態が変化した場合（たとえば、ユーザーアカウントの名前が変更された場合）、応答コードは301（「永久に移動」）になり、Locationヘッダーに新しいURIが提供されます。

オブジェクトが削除されると、応答コードは200（「OK」）になります。

詳細については、以下のリンクに従ってください- 残りのステータスコード