15 年間のステートフル クライアント/サーバー ソフトウェア開発の経験 (そしてそれには固有の問題があります) を持つ私は、RestFul アーキテクチャにおけるステートレスの概念をまだ理解しようとしています。
ビジネス・オブジェクトを REST サービスにポストする汎用インターフェースがあるとします。たとえば、ユーザー リソース。ユーザー リソースには、電子メール アドレスの一意性に関する制約が必要です。私の最初の反応は、基礎となるデータベース機能を使用してこれを「保証」することです。2 番目の反応は、何らかのロックまたはトランザクション メカニズムを導入することです。
しかし、私のレスファリアンの同僚は、「いいえ！」と答えます。クライアントは、新しいユーザーの電子メールが一意であるかどうかを確認する必要があり、重複した電子メール アドレスが挿入される可能性があるわずかな時間枠があるという事実を受け入れる必要があります。クライアント アプリケーションは、この競合を処理できる必要があります。
これは、私が学んだことすべてに反し、まったく自然に感じられません。教えてください...
適切なHTTP コード: 409 Conflictを返さない理由はありません。これは、データベースからエラーを取得したときに返される可能性があります。
リクエストを送信する前に電子メール アドレスが一意であるかどうかを確認すると、ユーザーに問題を修正するよう促す (および送信を無効にする) ことができるので、使いやすさの点で便利です。いずれにせよ、サーバー側の検証は引き続き推奨されます。
これは、プロトコルのステートレス性とは関係ありません。ステートレス性は、サーバーがセッション関連の状態を保存するものであってはならないことを示しているだけです (http://en.wikipedia.org/wiki/Stateless_protocol)。
あなたの場合、ユーザー リソースはセッション状態ではありません。サーバーに保存され、サーバーによって公開される永続的なリソースです。ステートレスであるため、クライアントにこのチェックを強制する理由はありません (すべてのユーザー リソースを繰り返し取得してチェックすることにより)。サーバーに実行させる方が理にかなっています。このチェックが新しいユーザー リソースの POST の一部としてサーバーによって行われるか、このチェックを有効にする別のリソースが存在するかにかかわらず、サーバーはどちらの方法でもこのチェックを行うため、本質的に違いはありません。別のリソースを使用して、最初に新しいユーザーを POST しても問題ないかどうかを確認してから、実際に POST を実行するための新しい要求を作成すると、電子メール アドレスが重複する可能性があります。そのような場合、
要するに、サーバーは「チェック」を行い、クライアントは、サーバーがチェックに失敗したことを通知する状況を処理できる必要があります。