我一直在研究演员模型一段时间，并试图找出如何将其与RESTful API正确结合。我正在努力如何分离两个层的责任，无论是通过使用ask-pattern还是actor-per-request。对于这两种模式，请求 - 回复语义都泄漏到actor模型中，这看起来像是一种反模式。大多数由HTTP请求发起的消息发送给演员需要回复。接收参与者有多个条件，它需要指示API无法完成请求。将演员模型与RESTful API结合
此外，什么被认为是输入验证的良好做法;这应该作为HTTP的一部分来实现（例如，如果字段X是有效的电子邮件地址，如果字段Y包含整数）。对于复杂的领域逻辑，演员在（前）条件失败时应该如何/应该通知发件人？
虽然请求/回复是在演员间通信中的反模式，但没有任何东西可以用来从演员系统之外使用它。您可以从那里使用Ask，并使用Forward + Tell的组合返回原始发件人发送回复，而不必使用演员内部的请求/回复模型。
当涉及到输入验证，ofc简单验证（现场存在，电子邮件格式等）可以很容易地在web框架的水平上完成。然而，更高级的案例（如权限管理）可能会使用角色 - 至少如果您的业务逻辑也使用它们。
对于复杂的场景 - 尝试用协议思考。描述参与者和/或外部服务之间的一组合约，并使用消息来控制逻辑的流程。通常很难描述这种推理，但通常用铅笔绘制通常很容易;）
即，你可以决定使用某种AuthorizationGate actor，它给出一个无法理解的请求，将验证它：在auth失败时，它将一些RequestFailed消息发回给原始发送者（提问者），成功时它可以将该消息转换为ValidRequest并发送它给负责处理该消息类型的actor。然后，一个actor（只处理有效请求）处理它，发送RequestSucceed或RequestFailed回原始发件人（记住将该发件人存储为消息字段，或者使用actorRef.Forward而不是actorRef.Tell，以便不覆盖它）。