重要なのは、特定のステータス コードが使用されたときのクライアントとキャッシュの期待を調べることです。
見るのに役立つ RFC2616 の一部を次に示します。
10.4.1. 400不正な要求
構文が正しくないため、サーバーは要求を理解できませんでした。クライアントは、変更なしでリクエストを繰り返すべきではありません。
これは、リクエスト自体が構文的にもプロトコル的にも完全に間違っていることを示しています。あなたの特定のケースは実際にはアプリケーションプロトコルエラーであるため、これは実際に適切かもしれません.
10.4.6. 405メソッドは許可されていません
Request-URI で識別されるリソースに対して、Request-Line で指定されたメソッドは許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含む Allow ヘッダーが含まれている必要があります。
これは一時的なステータス コードです。DELETEが具体的に連絡先リソース自体を参照している場合(例: DELETE /contacts/D9DF5176-EEE4-4C70-8DA7-BA57B82027A8)、これはおそらく最も適切なステータス コードです。ただし、DELETEが別のリソースまたはクエリを含むリソース (例: DELETE /contacts?index=12) にある場合は、405 を返しません。また、通常DELETE、クエリに似たものを使用することは避けます。
10.4.10. 409 紛争
リソースの現在の状態と競合するため、要求を完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。応答本文には、ユーザーが競合の原因を認識するのに十分な情報を含める必要があります。理想的には、応答エンティティには、ユーザーまたはユーザー エージェントが問題を解決するのに十分な情報が含まれます。ただし、それは不可能な場合があり、必須ではありません。
一見すると、これが最も適切なステータスのように思えます。あなたの場合、私はおそらく400を好むでしょう。409 は、リソースとの競合があることを明確に示しますが、リソースを完全に変更する (つまり、最初に連絡先を追加する) 以外に結果を変更する可能性があるリクエスタが実際にできることは何もありません。409 応答のほとんどは、取得後に変更されたリソースを変更しようとするなど、楽観的な同時実行エラーでした。たとえば、Apache Adbera で構築された AtomServer によって返される同時実行エラーを見てください。
それで、そのすべてで。私はおそらく400 Cannot Delete Last Contact応答ラインとしてのようなものを使用するでしょう. ステータス コードに関連付けられたフレーズは変更できることに注意してください。このようなことをするのは本当に良い時期です。