Rest API和DDD

发布时间：2020-12-14 00:51:53 所属栏目：百科来源：网络整理

导读：在我的项目中使用DDD方法。该项目有聚合(实体)交易。这个聚合有很多用例。对于这个聚合，我需要创建一个rest api。用标准：创建和删除没问题。 1)CreateDealUseCase(名称，价格和许多其他参数); POST /rest/{version}/deals/{ 'name': 'deal123','price':

在我的项目中使用DDD方法。

该项目有聚合(实体)交易。这个聚合有很多用例。

对于这个聚合，我需要创建一个rest api。

用标准：创建和删除没问题。

1)CreateDealUseCase(名称，价格和许多其他参数);

POST /rest/{version}/deals/
{ 
   'name': 'deal123','price': 1234;
   'etc': 'etc'
}

2)DeleteDealUseCase(id)

DELETE /rest/{version}/deals/{id}

但是如何处理其他用例呢？

> HoldDealUseCase(id，reason);
> UnholdDealUseCase(id);
> CompleteDealUseCase(id和许多其他参数);
> CancelDealUseCase(id，amercement，reason);
> ChangePriceUseCase(id，newPrice，reason);
> ChangeCompletionDateUseCase(id，newDate，amercement，whyChanged);
>等(共20个用例)……

有什么解决方案？

1)使用动词：

PUT /rest/{version}/deals/{id}/hold
{ 
   'reason': 'test'
}

但！动词不能在url中使用(在REST理论中)。

2)使用完成状态(将在用例之后)：

PUT /rest/{version}/deals/{id}/holded
{ 
   'reason': 'test'
}

就个人而言，它看起来很难看。也许我错了？

3)对所有操作使用1 PUT请求：

PUT /rest/{version}/deals/{id}
{ 
   'action': 'HoldDeal','params': {'reason': 'test'}
}

PUT /rest/{version}/deals/{id}
{ 
   'action': 'UnholdDeal','params': {}
}

在后端很难处理。
而且，很难记录。由于1个动作具有许多不同的请求变体，因此已经依赖于特定的响应。

所有解决方案都有明显的缺点。

我在网上看过很多关于REST的文章。到处都只有一个理论，如何与我的具体问题在一起？

I have read many articles about the REST on the internet.

根据我在这里看到的内容，你真的需要至少观看Jim Webber关于REST和DDD的谈话

> Rest in Practice
> Domain Driven Design for RESTful Systems

But what to do with the rest of the use cases?

暂时忽略API – 你将如何使用HTML表单？

你可能有一个网页，呈现交易的代表，上面有一堆链接。一个链接会将您带到HoldDeal表单，另一个链接会将您带到ChangePrice表单，依此类推。这些表单中的每一个都将填充零个或多个字段，并且每个表单都会发布到某个资源以更新域模型。

他们都会发布到相同的资源吗？也许，也许不是。它们都具有相同的媒体类型，因此如果它们都发布到同一个Web端点，则必须解码另一侧的内容。

鉴于这种方法，您如何实现您的系统？嗯，根据你的例子，媒体类型想成为json，但其余部分确实没有任何问题。

1) Use verbs:

没关系。

But! Verbs can not be used in the url(in REST theory).

不。 REST不关心资源标识符的拼写。有一堆URI最佳实践声称动词是坏的 – 这是真的 – 但这不是来自REST的东西。

但是如果人们如此挑剔，你可以命名命令的端点而不是动词。 (即：“hold”不是动词，它是一个用例)。

Use 1 PUT request for all operations:

老实说，那个也不错。您不希望共享uri(因为指定了PUT方法)，但使用模板，客户端可以在其中指定唯一标识符。

这是肉：你正在HTTP和HTTP动词之上构建一个api。 HTTP专为文档传输而设计。客户端为您提供一个文档，描述您的域模型中所请求的更改，并将更改应用于域(或不是)，并返回描述新状态的另一个文档。

暂时借用CQRS词汇表，您将发布更新域模型的命令。

PUT /commands/{commandId}
{ 
   'deal' : dealId
   'action': 'HoldDeal','params': {'reason': 'test'}
}

理由 – 您将特定命令(具有特定Id的命令)放入命令队列(这是一个集合)。

PUT /rest/{version}/deals/{dealId}/commands/{commandId}
{ 
   'action': 'HoldDeal','params': {'reason': 'test'}
}

是的，那也没关系。

再看一下RESTBucks。这是一个咖啡店协议，但所有api只是通过小文件来推进状态机。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!