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