如何设计一个动作但有两个不同含义的RESTAPI？_Rest_Domain Driven Design_Webapi

如何设计一个动作但有两个不同含义的RESTAPI？

rest domain-driven-design

如何设计一个动作但有两个不同含义的RESTAPI？,rest,domain-driven-design,webapi,Rest,Domain Driven Design,Webapi,给出了带有订单资源的车间API示例。您希望按id删除一个订单删除/orders/：orderId 在引擎盖下，您运行更新查询并将cancelled设置为true。但是如果客户将此端点称为：您需要一个canceledByCustomer数据库标志不需要其他权限管理员调用此端点？您需要一个rejectedByAdministrator数据库标志需要其他权限如果调用用户试图取消另一个用户的订单，并且如果为true，这是拒绝操作，您是否会将端点张贴在上面并在内部进行检查

给出了带有

订单

资源的车间API示例。您希望按id删除一个订单

删除/orders/：orderId

在引擎盖下，您运行更新查询并将

cancelled

设置为

true

。但是如果

客户将此端点称为：
- 您需要一个
```
canceledByCustomer
```
  数据库标志
- 不需要其他权限
管理员调用此端点？
- 您需要一个
```
rejectedByAdministrator
```
  数据库标志
- 需要其他权限

如果调用用户试图取消另一个用户的订单，并且如果为true，这是拒绝操作，您是否会将端点张贴在上面并在内部进行检查

是否添加两个查询参数

cancel

和

reject

，其中一个必须为true，另一个必须为null/false

您是否会违反设计规则，创建两个不同的端点并像这样向它们添加谓词

DELETE/orders/：orderId/cancel=>客户可以调用它

DELETE/orders/：orderId/reject=>只有管理员才能调用它

有人知道这种“域驱动”问题的最佳实践吗？

API端点不必与核心附近发生的事情相关联，例如在聚合根或CommandHandler中。在我看来，让API路由尽可能详细，这意味着为每个用例创建它们自己的单独路由。将要使用的数据库标志上的逻辑（canceledByCustomer vs rejectedByAdministrator）推到更靠近实体的位置