我一直在研究演員模型一段時間，並試圖找出如何將其與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，以便不覆蓋它）。