私はしばらくアクター モデルを研究しており、それを RESTful API と正しく組み合わせる方法を見つけようとしています。ask-pattern または Actor-per-request を使用して、両方のレイヤーの責任を分離する方法に苦労しています。どちらのパターンでも、リクエストとリプライのセマンティクスがアクター モデルに漏れており、これはアンチ パターンのように見えます。HTTP 要求によって開始され、アクターに送信されるほとんどのメッセージには、応答が必要です。受信側のアクターには、リクエストを実行できない API を通知する必要がある複数の条件があります。
さらに、入力の検証に関して良い習慣と見なされるもの。これを HTTP の一部として実装する必要があります (たとえば、フィールド X が有効な電子メール アドレスである場合、フィールド Y が整数を保持している場合)。また、複雑なドメイン ロジックの場合、(事前) 条件が失敗した場合、アクターは送信者にどのように通知する必要がありますか?
リクエスト/リプライはアクター間の通信におけるアンチパターンですが、アクター システムの外部からそれを使用することを邪魔するものは何もありません。Askそこから使用でき、元の送信者に戻るForward+の組み合わせを使用して、必ずしもアクター内で要求/応答モデルを使用せずに応答を送信できます。Tell
入力の検証に関して言えば、単純な検証 (フィールドの存在、電子メール形式など) は、Web フレームワークのレベルで簡単に実行できます。ただし、より高度なケース (パーミッション管理など) では、おそらくアクターを使用します (少なくともビジネス ロジックでアクターも使用する場合)。
複雑なシナリオの場合 - プロトコルで考えてみてください。アクターや外部サービス間の一連の契約を記述し、メッセージを使用してロジックのフローを制御します。通常、そのような推論を説明するのは難しいですが、鉛筆で描くのは通常非常に簡単です ;)
AuthorizationGateつまり、承認されていないリクエストが与えられた場合、それを検証する何らかの種類のアクターを使用することを決定する場合があります。認証に失敗するとRequestFailed、元の送信者 (質問者) にメッセージを送り返し、成功すると、そのメッセージを変換して送信することができますValidRequest。そのメッセージ タイプの処理を担当するアクター。次に、アクター (有効な要求のみを処理する) がそれを処理し、元の送信者に送信RequestSucceedまたはRequestFailed返信します (その送信者をメッセージ フィールドとして保存するか、actorRef.Tell の代わりにactorRef.Forward を使用して上書きしないようにしてください)。