「このメールはすでに登録されています」のHTTP応答コードはどれですか？
一意のメールアドレスを適用するユーザーを作成するためのRESTful APIを作成しています。
成功POST /users：HTTP 201 Created
同じ電子メールアドレスを再度POSTした場合、応答コードはどうなりますか？ 409 Conflict適切な応答コード？
はい、ここでは 409 が最も適切な応答コードです。成功すると201を返す可能性が最も高いですが、コレクションとして記述されているリソースにPOSTしているため、重複したメールをPOSTすると、コレクションとしての「リソースの現在の状態」とは明らかに矛盾します。問題の説明を含む応答本文と、可能であれば問題の解決に役立つハイパーリンクを返す必要があります。
既存の登録済みメールに対して409 Conflictを返すことに本当に満足していません-私の意見では、これはクライアントのエラーではありません。それでは、いくつかの大手テクノロジー企業がそのケースをどのように処理しているか（少なくとも、WebサイトAPIでどのように処理しているか）を見てみましょう。
Gmail（Google）は、200 OKと、メールがすでに登録されていることを示すコードを含むJSONオブジェクトを返します。
Facebookも200 OKを返しますが、コンテンツをリカバリページに再レンダリングして、ユーザーに既存のアカウントをリカバリするオプションを提供します。
Twitterは既存のメールをAJAX呼び出しで別のリソースに検証しています。メール検証リソースの応答は常に200 OKです。応答にはメールがすでに登録されているかどうかを示すフラグを含むJSONオブジェクト。
AmazonはFacebookと同じ方法で実行しています。 200 OKを返し、コンテンツを通知ページに再レンダリングして、アカウントがすでに存在することをユーザーに通知し、ログインやパスワードの変更などの追加アクションを実行する可能性を提供します。
したがって、これらすべてのAPIは常に200 OKを返し、クライアント/ユーザーに、アカウントを回復するための追加コンテンツ、または応答の本文コンテンツによって生成されるエラーメッセージを提示します。
承認された答えはタスクの正しいステータスコードを表示するのに正しいですが、セキュリティの脆弱性を導入していることを付け加えておきます。
アカウント登録のために409を返す場合は、アカウント列挙のためにサービスを公開しているだけです。
アプリケーションによっては、APIが公開されているかどうかなどによって、アカウントが作成されていなくても201を返す必要がある場合があります。
+1からBartsへの回答-セキュリティ上の理由から。通常、409はsthの適切なステータスコードであることに同意します。それはすでに存在しています。しかし、ユーザーアカウント/認証/承認などの環境では、データベース内の既存のユーザーアカウントを公開しない傾向があります。
もちろん、この場所にはセキュリティを処理する他のメカニズムがあります。少数のアカウントを公開しても構わない場合は、1つのIPからの多数の409イベントで401または403を返す動作をアプリケーションに追加できます。
別のオプション（一般的に）は、既存の標準2xxバリアントとは異なる2xxを持つように自分でステータスコードを定義することです。これは、「すでに存在する」をエラーとして処理したくない場合のオプションです。ただし、これは非標準と見なされ、具体的な例では409のような同じ安全でない特性を持ちます。
私はよく使用します（WebDAV拡張）HTTP 422処理できないエンティティ ：
リクエストは整形式でしたが、セマンティックエラーが原因で追跡できませんでした