検証の失敗または無効な重複のREST HTTPステータスコード

RESTベースのAPIを使用してアプリケーションを構築していて、各リクエストのステータスコードを指定するようになりました。

検証に失敗したリクエスト、またはリクエストがデータベースに重複を追加しようとしている場合、どのステータスコードを送信する必要がありますか？

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.htmlを確認しましたが、どれも正しくないようです。

ステータスコードを送信する際の一般的な方法はありますか？

入力検証失敗の場合：400 Bad Request +オプションの説明。これは、本「RESTful Web Services」で提案されています。二重送信の場合：409競合

2014年6月の更新

関連する仕様は、以前はRFC2616でしたが、400（Bad Request）の使用がかなり狭くなりました。

不正な構文のため、サーバーはリクエストを理解できませんでした

したがって、セマンティックエラーには不適切であると主張された可能性があります。もうそうじゃない; 2014年6月以降、関連する標準RFC 7231は以前のRFC2616に取って代わり、400（Bad Request）の使用をより広く

サーバーは、クライアントエラーと認識されていることが原因で要求を処理できない、または処理しません

• 検証に失敗しました：403 Forbidden（「サーバーは要求を理解しましたが、実行を拒否しています」）。世論に反して、RFC2616は「403は失敗した認証のみを目的としている」とは述べていませんが、「403：何をしたいのかはわかっていますが、私はしません」と述べています。その状態は、認証が原因である場合とそうでない場合があります。
• 重複を追加しようとしています：409競合（「リソースの現在の状態と競合しているため、リクエストを完了できませんでした。」）

あなたは間違いなく応答ヘッダーやボディでより詳細な説明を与えるべきです（例えばカスタムヘッダー-でX-Status-Reason: Validation failed）。

ステータスコード422、 "Unprocessable Entity"をお勧めします。

11.2 422処理できないエンティティ

422（Unprocessable Entity）ステータスコードは、サーバーがリクエストエンティティのコンテンツタイプを理解しているため（415（Unsupported Media Type）ステータスコードが不適切）、リクエストエンティティの構文が正しい（つまり、400（Bad Request ）ステータスコードは不適切）ですが、含まれている指示を処理できませんでした。たとえば、XMLリクエストの本文に整形式（つまり、構文的には正しい）が含まれているが、意味的には誤りのあるXML命令が含まれている場合に、このエラー条件が発生することがあります。

200、300、400、500はすべて非常に一般的です。ジェネリックが必要な場合は、400で十分です。

422は、ますます多くのAPIで使用されており、Railsからそのまま使用されています。

APIにどのステータスコードを選択しても、誰かが反対するでしょう。しかし、私は「400 +テキストステータス」が一般的すぎると思うので、422を好みます。また、JSON対応のパーサーを利用していません。対照的に、JSON応答を伴う422は非常に明示的であり、大量のエラー情報を伝えることができます。

JSON応答といえば、この場合のRailsエラー応答を標準化する傾向があります。

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

この形式はフォーム検証に最適です。これは、「エラー報告の豊富さ」の観点からサポートする最も複雑なケースと考えています。エラー構造がこれである場合、エラー報告のすべてのニーズを処理する可能性があります。

200

うーん...（309、400、403、409、415、422）... 成功したHTTPリクエストが失敗したRESTコールの最良のリターンコードは何かを推測、議論、標準化しようとする多くの回答。

HTTPステータスコードとRESTステータスコードを混在させるのは間違っています。

しかし、多くの実装がそれらを混合しているのを見たので、多くの開発者が私に同意しないかもしれません。

HTTP戻りコードは、HTTP Requestそれ自体に関連しています。REST呼び出しは、ハイパーテキスト転送プロトコル要求を使用して行われ、呼び出されたRESTメソッド自体よりも低いレベルで機能します。RESTは概念/アプローチであり、その出力はビジネス/論理結果ですが、HTTP結果コードはトランスポートです。

たとえば、/ users /を呼び出したときに "404 Not found"を返すと混乱を招きます。

• URIが間違っている（HTTP）
• ユーザーが見つかりません（REST）

「403 Forbidden / Access Denied」とは、

• 特別な許可が必要です。ブラウザは、ユーザー/パスワードを尋ねることによってそれを処理できます。（HTTP）
• サーバーで構成されているアクセス権が間違っています。（HTTP）
• 認証する必要があります（REST）

また、リストは「500サーバーエラー」（Apache / Nginx HTTPスローエラーまたはRESTのビジネス制約エラー）または他のHTTPエラーなどで続行される場合があります。

コードから、失敗の理由、HTTP（トランスポート）の失敗、またはREST（論理）の失敗の原因を理解するのは困難です。

HTTPリクエストが物理的に正常に実行された場合、レコードが見つかったかどうかに関係なく、常に 200コードを返す必要があります。URIリソースが見つかり、HTTPサーバーによって処理されたためです。はい、空のセットが返される場合があります。HTTP結果として200の空のWebページを受け取ることは可能ですか？

これの代わりに、いくつかのオプションを使用して200 HTTPコードを返すことができます。

• 何か問題が発生した場合のJSON結果の「エラー」オブジェクト
• レコードが見つからない場合、空のJSON配列/オブジェクト
• より良い処理のための以前のオプションと組み合わせたブールの結果/成功フラグ。

また、インターネットプロバイダーによっては、リクエストを傍受して404 HTTPコードを返す場合があります。これは、データが見つからないという意味ではありませんが、トランスポートレベルで何か問題があります。

Wikiから：

2004年7月、英国の通信プロバイダーであるBT GroupはCleanfeedコンテンツブロッキングシステムを展開しました。このシステムは、Internet Watch Foundationによって違法である可能性があると識別されたコンテンツのリクエストに対して404エラーを返します。他のISPは、同じ状況でHTTP 403「禁止」エラーを返します。検閲を隠す手段として偽の404エラーを採用する慣行は、タイとチュニジアでも報告されています。2011年の革命以前は検閲が厳しかったチュニジアでは、人々は偽の404エラーの性質に気づき、「目に見えない検閲者」を表す「Ammar 404」という架空のキャラクターを作成しました。

単純にこのようなもので答えませんか？

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

リクエストが論理的に失敗した場合でも、Googleは常にGeocoding APIでステータスコードとして200を返します。https：//developers.google.com/maps/documentation/geocoding/intro#StatusCodes

RESTリクエストが失敗した場合でも、FacebookはHTTPリクエストが成功すると常に200を返します。https：//developers.facebook.com/docs/graph-api/using-graph-api/error-handling

シンプルで、HTTPステータスコードはHTTPリクエスト用です。REST APIは、あなたのステータスコードを定義します。

データベース内の複製は409 CONFLICTです。

422 UNPROCESSABLE ENTITY検証エラーに使用することをお勧めします。

ここで4xxコードのより長い説明をします。

ステータスコード304が変更されていない場合も、重複する要求に対して許容可能な応答を行います。これはIf-None-Match、エンティティタグを使用するヘッダーの処理に似ています。

私の意見では、@ Piskvorの答えは、元の質問の意図であると私が認識しているものに対するより明白な選択ですが、関連性のある代替案もあります。

重複する要求をエラーではなく警告または通知として扱いたい場合は、304Not Modifiedの応答ステータスコードとContent-Location既存のリソースを識別するヘッダーも同様に有効です。リソースの存在を確認することだけが目的の場合、重複したリクエストはエラーではなく確認になります。リクエストは間違っていませんが、単に冗長であり、クライアントは既存のリソースを参照できます。

つまり、要求は良好ですが、リソースはすでに存在しているため、サーバーはそれ以上の処理を実行する必要はありません。

Ember-DataのActiveRecordアダプターは422 UNPROCESSABLE ENTITY、サーバーから返されることを予期しています。したがって、クライアントがEmber.jsで記述されている場合は、422を使用する必要があります。そうしないと、DS.Errorsには返されたエラーが入力されます。もちろん、422をアダプターの他のコードに変更できます。