我已经研究了一段时间的演员模型，并试图弄清楚如何正确地将它与 RESTful API 结合起来。我正在努力如何通过使用 ask-pattern 或 actor-per-request 来分离两层的职责。对于这两种模式，请求-回复语义都会泄漏到参与者模型中，这似乎是一种反模式。大多数由 HTTP 请求发起的消息发送给参与者都需要回复。接收参与者有多个条件，它需要向无法满足请求的 API 发出信号。
此外，关于输入验证的良好做法是什么；这是否应该作为 HTTP 的一部分来实现（例如，如果字段 X 是有效的电子邮件地址，如果字段 Y 包含整数）。对于复杂的域逻辑，当（预）条件失败时，参与者如何/应该通知发送者？
虽然请求/回复是参与者间通信中的一种反模式，但在您从参与者系统外部使用它的方式上没有任何障碍。您可以Ask从那里使用Forward+Tell返回原始发件人的组合来发送回复，而不必在参与者内部使用请求/回复模型。
当涉及到输入验证时，可以在 Web 框架级别轻松完成简单的验证（字段存在、电子邮件格式等）。然而，更高级的案例（如权限管理）可能会使用参与者 - 至少如果您的业务逻辑也使用它们。
对于复杂的场景——试着用协议来思考。描述参与者和/或外部服务之间的一组契约，并使用消息来控制逻辑流。这种推理通常很难描述，但用铅笔画出来通常很容易；）
即你可能决定使用某种类型的AuthorizationGateactor，它给出一个未经授权的请求，将验证它：在身份验证失败时，它将一些RequestFailed消息发送回原始发送者（询问者），成功时它可以将该消息转换为ValidRequest并将其发送到负责处理该消息类型的参与者。然后一个actor（只处理有效请求），处理它，发送RequestSucceed或RequestFailed返回给原始发送者（记住要么将该发送者存储为消息字段，或者使用actorRef.Forward而不是actorRef.Tell，这样你就不会覆盖它）。