1

Web サービスのユーザー登録を実装しています。

誰かがアカウントを登録したいとき、私の WS はアクティベーション リンクを彼/彼女のメールに送信します。このリンクをクリックするまで、ユーザー アカウントはアクティブ化されません (ただし、情報はデータベースに保持されるため、リソースは存在します)。

私の質問は、同じメールを複数回登録しようとすると、409 CONFLICT コードが返されるということです。しかし、そこには 2 つのシナリオがあります。

  1. 確認待ちのユーザーアカウント
  2. ユーザーはすでに登録され、アクティブ化されています

正しいアプローチ方法を知りたいです。それらを区別するためにHTTPステータス4XXを「発明」するか、情報を含むJSONで409を送信する必要がありますか? 他の解決策？

どうも！

編集：

私はこの応答を見つけました-> https://stackoverflow.com/a/3290369/1171280 Piskvor は、409 ステータスと要求ヘッダーを使用して、失敗した理由や本文を説明することを提案しています。どれ？ヘッダ？体？両方？

どう思いますか？

編集2：

HTTP ステータス + 詳細なエラー (機械で解析可能なコードを含む) を含む本文は問題ありません。しかし、私はまだ403対409を疑っています... :S

4

4 に答える 4

2

HTTP ステータス コードは、「発明」されることを意図したものではありません。

409 CONFLICT私には問題ないように聞こえます。クライアントが知る必要がある場合は、本文に詳細を含めても問題ありません。

于 2013-06-07T07:34:16.157 に答える
2

409を使用しないでください。403を使用します。

[409] は、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。

これは、問題がないはずのリクエストですが、解決できる問題があります。ドキュメントとPUT改訂されたテキストを編集したが、他の誰かがあなたの前に同じことをした場合は、他の人の作業を見て、誤ってすべての作業を元に戻さないようにする必要があります。あなたは 409 を受け取ります。つまり、それを修正したい場合は、他の人が最新のリビジョンを見たことがあることを示すリビジョンを送信する必要があります。

冗長な登録試行を「修正」する方法はありません。競合を回避する唯一の方法は、別のユーザー名で登録することですが、それは非常に間違っています。

POSTユーザー名と電子メール アドレスを取得し、その新しいユーザー専用の新しいリソース (検証に使用する必要があります) を作成し、そのリソースの URL を電子メールで送信する要求を想像しています。POSTしたがって、アプリケーションのビジネス モデルに固有の理由 (不適切な構文などの HTTP 関連の理由ではなく) で、要求ハンドラーが新しいリソースを作成することを拒否することに対処しています。

403 よりも具体的なステータス コードはありません。この場合、HTTP の語彙を使用して通信する必要があるのは、「許可されていません」だけです。HTTP の上にあるレイヤーを使用して、丁寧な HTML ページやクライアントが理解し、丁寧な HTML ページとしてレンダリングするための JSON オブジェクト。

于 2013-06-08T10:10:40.447 に答える
2

保留中のアカウントは特別なタイプのユーザー アカウントであるため、質問の文脈では両方のアカウント (登録済みと保留中) は同じだと思います。どちらの場合も 409 を返す必要があります。REST API の場合、そのリソースはシステムに既に存在するため、どちらも同じケースです。

更新された質問については、カスタム HTTP ヘッダーを使用して呼び出しが失敗した理由を説明する代わりに、本文 (JSON) を使用してエラーを送信することをお勧めします。その理由は、本文には複数のエラー メッセージ (それぞれが個別の JSON オブジェクト/配列要素として) を含めることができるのに対し、ヘッダーには 1 つのみを含めることができるからです (ただし、一部の文字に基づいて分割することはできます)。その他の理由は、失敗のシナリオごとに異なるカスタム ヘッダーを探す代わりに、JSON 内の「エラー」オブジェクトを探す 1 つの一般的なエラー処理メソッドを使用できることです。

HTTP コード:

403 - サーバーはリクエストを理解しましたが、リクエストの実行を拒否しています。承認は役に立たず、要求を繰り返すべきではありません。

409 - リソースの現在の状態と競合するため、リクエストを完了できませんでした。このコードは、ユーザーが競合を解決してリクエストを再送信できると予想される状況でのみ許可されます。

別のメールアドレスでリクエストを再発行することで競合が解決できるため、409 にする必要があると思います。

于 2013-06-07T07:39:23.880 に答える
0

409 は問題ないはずです。詳細については、https://datatracker.ietf.org/doc/html/draft-nottingham-http-problem-04が興味深いかもしれません。

于 2013-06-07T07:48:23.533 に答える