我正在实现一个基于CQRS/ES的系统，该系统具有Web应用程序使用的RESTful接口。
当执行某些操作时，例如创建新的配置文件时，我需要能够检查某些条件，例如配置文件ID的唯一性，或者此人是否有权在组下创建资源。这意味着我有几个选择：
上下文：POST/profiles { "email": "unique@example.com" }
-
通过我的REST API从我的服务返回
202，其中包含新资源的位置，我的客户端可以在该位置轮询它。但是，在这种情况下，我如何处理错误，因为实际上视图将不存在或永远不存在。 -
在初始请求上创建一个传奇，然后分派事件。一旦我的服务创建了视图或发现了错误，结果就会写入传奇。当传奇故事完成后，将结果返回给用户。
从这两个选项来看，第二个对我来说似乎更合理，如果不是更复杂的话。这是在CQRS/ES事件源后端构建RESTful请求/响应模型的可行选项吗？
是的，第二个解决方案似乎更适合业务。
根据我从您的案例中了解到的情况，从DDD的角度来看，创建用户配置文件是一个业务流程，需要多个步骤(验证配置文件的唯一性、创建配置文件以及从重复的配置文件情况中恢复(。这个过程就像一个实体，它开始、运行并以结果(成功或错误(结束。作为一个实体，它有一个ID，可以被视为REST资源。佐贺将负责执行它。
因此，为了响应客户端的请求，您发送流程资源的URI，客户端可以在其中轮询状态。如果出现错误，它将读取错误消息。如果成功，它将获取其配置文件的URI。
如果用例更简单，如果命令可以同步执行，并且客户端获得最终结果(错误或成功(作为即时响应，则仍然可以使用第一个解决方案。
从我的REST API返回202，从我的服务返回新资源的位置，我的客户端可以在那里轮询它。但是，在这种情况下，我如何处理错误，因为实际上视图将不存在或永远不存在。
这里的常见答案是，作为202接受响应的一部分，您包括监控信息
与此响应一起发送的表示应该描述请求的当前状态，并指向(或嵌入(一个状态监视器，该监视器可以为用户提供请求何时完成的估计。
换句话说，指向资源的链接，当接受的请求最终运行时，该链接将发生更改。
因此，在描述协议时，除了您创建的资源外，还需要记录将工作推迟到以后时使用的表示形式，以及监视器使用的表示方式。
传奇故事完成后，将结果返回给用户。
根据工作的不同，这可能有些过头了。
也就是说，你在这里提出了两个不同的问题；其中之一是应该同步处理请求(在工作完成之前不要响应(还是异步处理请求(立即返回，但为客户端提供监视进度的方法(。
另一个问题是，从业务层看，这项工作看起来怎么样。如果您将需要多个事务来进行更改，并且如果您可能需要"；恢复"；以前在流程的某些变体中提交的事务，那么传奇(或流程管理器(是有意义的。
Set Validation(设置验证(——更广泛的术语，用于强制执行一个类似"；唯一性"——很尴尬。确保你进行了研究，并确保你和企业了解失败的影响。