如何在REST,CQRS和EventSourcing一起支持REST中的Command？

Question

考虑以下针对Contact资源的粗粒度REST apis

POST          /api/contacts                             
GET           /api/contacts                             
GET           /api/contacts/:id                         
PUT           /api/contacts/:id                         
DELETE        /api/contacts/:id                         

考虑使用事件源作为联系人资源,即验证命令并存储事件.因此必须存储每个事件,包括每个字段级别的更改.

CreateContactCommand -> | Contact("john", "doe", 25) | -> ContactCreatedEvent
FirstNameChangeCommand -> | Contact("jane", "doe", 25) | -> FirstNameChangedEvent
LastNameChangeCommand -> | Contact("jane", "dear", 25) | -> LastNameChangedEvent
AgeChangeCommand -> | Contact("jane", "doe", 30) | -> AgeChangedEvent

现在,将REST和EventSourcing结合起来.

做REST,客户端如何与上述标准REST API进行通信以进行字段级更改,以便在服务器端REST端点生成命令？

主要问题是,如何设计REST API以便它还可以支持最终支持事件的命令？

如果有人能够阐明这一点,我们将非常感谢你的帮助.

Answer 1

CQRS和事件Sourcing既不是API设计原则,也不是顶级架构.但是,如果您希望将API"公开"为基于任务的API,则可以将链接公开为联系人资源的一部分.

GET /contacts/1234

响应

200 OK
<contact>
  <atom:link href="/contacts/1234/first-name" rel="first-name" />
  <atom:link href="/contacts/1234/last-name" rel="last-name" />
  <atom:link href="/contacts/1234/age" rel="age" />
  <first-name>Jane</first-name>
  <last-name>Doe</last-name>
  <age>25</age>
</contact>

这里的假设是您将API更改为真正的 3级 REST API.

此外,/contacts/1234只接受GET和DELETE(不 PUT)请求.如果客户想要更改例如联系人的名字,则必须遵循关系类型的链接first-name并PUT针对该资源发出请求:

PUT /contacts/1234/first-name
<first-name>John</first-name>

还有什么比一个first-name场PUT在这里应该被忽略或拒绝.

因此,当服务收到PUT针对名字资源的邮件时,它是一个更改联系人名字的命令.

这仍然不是一个适当的基于任务的API,因为它没有捕获为什么名字改变,但我希望你明白这个想法.