CQRS和REST HATEOAS不匹配 [英] CQRS and REST HATEOAS mismatch
问题描述
假设您有一个模型Foo。
一个业务案例是简单地创建Foo的实例，因此在我的模型中有一个对应的CreateFooCommand，是通过向给定的REST端点调用POST请求来触发的。
当然还有其他命令。
但是现在有一个ViewModel，它是从DomainModel中派生的。它只是一个包含原始数据的sql表-DomainModel中的每个Foo实例都有对应的派生ViewModel实例。两者都有不同的ID（在DomainModel上有一个DomainID，在ViewModel上只是一个 long 值）。
现在：在这种情况下，我什至应该关心HATEOAS吗？在适当的REST实现中，我至少应该在标头中返回location-url。但是由于我的视图模型仅从DomainModel派生，所以我应该关心吗？创建DomainModel时，我什至没有该视图模型的ID。
由于CQRS意味着查询是分开的在Commands中，您可能无法立即执行查询，因为该Command可能尚未应用（也许永远不会应用）。
为了与HATEOAS协调，而不是从POST请求中返回200 OK，该服务可以返回 202接受：
该请求已被接受处理，但处理尚未完成。该请求最终可能会执行，也可能不会最终执行，因为在实际进行处理时可能会不允许该请求。无法从这样的异步操作中重新发送状态代码。
202的响应是有意不提交的。其目的是允许服务器接受对其他进程的请求（也许是每天仅运行一次的面向批处理的进程），而无需用户代理与服务器的连接一直持续到该进程完成为止。返回此响应的实体应该包括请求当前状态的指示以及状态监视器的指针或用户何时可以期望完成请求的一些估计。
b $ b
（我的重点）
该指针可能是客户端可以查询以获取Command状态的链接。当/如果命令完成并且更新了视图，则该状态资源将包含指向该视图的链接。
这几乎就是 REST在实践中-非常让人联想到 Restbucks 示例。
另一种选择解决ID问题的方法是在接受命令之前生成ID-甚至可能要求客户端提供ID。在此处中了解详情。。 p>
Suppose you have a model Foo. One business case is to simply create an instance of Foo, so there is a corresponding CreateFooCommand in my model, triggered by invoking a POST request to a given REST endpoint.
There are of course other Commands too.
But now, there is a ViewModel, which is derived from my DomainModel. It's simply a sql table with raw data - each Foo instance from DomainModel has corresponding derived ViewModel instance. Both have different IDs (on DomainModel there is a DomainID, on ViewModel it's simply a long value).
Now: should I even care about HATEOAS in such a case? In a proper REST implementation, I should at least return location-url in the header. But since my view model is only derived from DomainModel, should I care? I don't even have the view model's ID at the time my DomainModel is created.
Since CQRS means that Queries are separated from Commands, you may not be able to perform a Query right away, because the Command may not yet have been applied (perhaps it never will).
In order to reconcile that with HATEOAS, instead of returning 200 OK from the POST request, the service can return 202 Accepted:
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
(My emphasis)
That pointer could be a link that the client can query to get the status of the Command. When/if the Command completes and the View is updated, that status resource could then contain a link to the view.
This is pretty much a workflow straight out of REST in Practice - very reminiscent of its Restbucks example.
Another option to deal with the ID issue is to generate the ID before accepting the Command - perhaps even asking the client to supply the ID. Read more about such options here.
这篇关于CQRS和REST HATEOAS不匹配的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
