947

REST ベースの API を使用してアプリケーションを構築しており、各リクエストのステータス コードを指定するところまで来ました。

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

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

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

4

8 に答える 8

894

入力検証エラーの場合: 400 Bad Request + オプションの説明。これは、書籍「RESTful Web サービス」で提案されています。二重送信の場合: 409 Conflict

2014 年 6 月の更新

関連する仕様は以前はRFC2616であり、400 (Bad Request) を狭い範囲で使用していました。

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

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

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

于 2010-07-20T13:05:04.603 に答える
285
  • 検証に失敗しました：403 Forbidden（ "サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています"）。世論に反して、RFC2616は「403は認証の失敗のみを目的としている」とは言っていませんが、「403：あなたが何を望んでいるのかはわかっていますが、それはしません」と言っています。その状態は、認証が原因である場合とそうでない場合があります。
  • 重複を追加しようとしています：409競合（「リソースの現在の状態との競合のため、リクエストを完了できませんでした。」）

応答ヘッダーや本文（カスタムヘッダーなどX-Status-Reason: Validation failed）で、より詳細な説明を確実に提供する必要があります。

于 2010-07-20T13:24:04.537 に答える
263

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

11.2. 422 処理不能エンティティ

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

于 2010-07-20T14:56:26.783 に答える
91

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", ...]
    }
}

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

于 2013-04-04T17:40:59.957 に答える
5

ステータス コード 304 Not Modifiedも、重複したリクエストに対して許容可能な応答を行います。If-None-Matchこれは、エンティティ タグを使用したヘッダーの処理に似ています。

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

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

つまり、リクエストは適切ですが、リソースがすでに存在するため、サーバーはそれ以上の処理を実行する必要はありません。

于 2014-03-17T19:14:39.133 に答える