RESTFulアーキテクチャ内のユニークな制約

Question

15年のステートフルなクライアント/サーバーソフトウェア開発経験（それには固有の問題があります）は、RestFulアーキテクチャでステートレス性の概念を把握しようとしています。

ビジネスオブジェクトをRESTサービスに送信するための汎用インターフェースがあるとします。たとえば、ユーザーリソース。私のユーザリソースは、自分の電子メールアドレスの一意性に制約があります。私の最初の反応は、これを「ガーメント」するために基礎となるデータベース機能を使用することです。第2の反応は、いくつかのロックメカニズムまたはトランザクションメカニズムを導入することです。

私のRestafarianの同僚は、「いいえ！」と応答します。クライアントは、新しいユーザーの電子メールが一意であるかどうかを確認し、重複する電子メールアドレスを挿入できる小さなウィンドウがあるという事実を受け入れるだけですべきです。クライアントアプリケーションはこの競合を処理できるはずです。

これは、私が学んだすべてのものに反するものであり、全く自然に感じられません。私に教えてください...

Answer 1

私は適切なものを返さない理由はありませんHTTP code：409競合。これは、データベースからエラーが発生したときに返されます。

ユーザビリティ上の理由から、ユーザにプロンプ​​トを表示して問題を解決できるように電子メールアドレスが一意であるかどうかを確認することは良いことです。いずれにしても、サーバー側の検証は依然として推奨されます。

Answer 2

これはプロトコルのステートレス性とは関係ありません。ステートレス性は、サーバーがセッション関連の状態を保存するものであってはならないとしか言​​いません（http://en.wikipedia.org/wiki/Stateless_protocol）。

あなたの場合、ユーザーリソースはセッション状態ではありません。これらのリソースはサーバーに保存され、サーバーによって公開されます。クライアントに（すべてのユーザーリソースを繰り返しフェッチしてチェックすることによって）このチェックを行わせる無国籍性の理由はありません。また、サーバーにそれをさせるのが理にかなっています。このチェックが新しいUserリソースのPOSTの一環としてサーバーによって行われるか、このチェックを可能にする別個のリソースが存在するかは、サーバーがこのチェックをどちらの方法で行っても実質的に違いはありません。別のリソースを使用して新しいユーザーをPOSTしてから実際にPOSTを実行するように新しい要求を行うことを確認する場合は、重複する電子メールアドレスが存在する可能性があります。そのような場合、予想される動作は、POST要求が失敗したことをクライアントに通知することです（適切なHTTP応答コードを使用して、クライアントが電子メールが正常であることを確認した最初の要求と同様です）。

要するに、サーバーは「チェック」を行い、クライアントはチェックが失敗したことをサーバーが通知する状況を処理できるはずです。