使用.NET 6开发TodoList应用(10)——实现DELETE请求以及HTTP请求幂等性

系列导航及源代码

使用.NET 6开发TodoList应用文章索引

需求

先说明一下关于原本想要去更新的PATCH请求的文章，从目前试验的情况来看，如果是按照.NET 6的项目结构（即只使用一个Program.cs完成程序初始化），那微软官方给出的文档目前还没有对应地更新，按照之前的方式进行JsonPatch的配置是不行的，目前已经有人在Github微软的官方文档Repo下提了ISSUE: .NET 6: JsonPatch in ASP.NET Core web API。并且因为PATCH的使用频率并不高，所以我暂时跳过那篇，先把进度继续往后走，看微软什么时候把这个issue解决一下我再看情况把PATCH那一节补上。

本文我们来看最后一个常用HTTP请求类型：DELETE。

目标

实现并验证应用正确处理DELETE请求。并对HTTP请求的幂等性做简单的介绍。

原理与思路

经过关于Create、Update、Get的实现，对于Delete的实现我们的思路是很清晰的。我们需要创建Delete的Command及其Handler，然后在Controller中通过Mediatr发送请求即可。

实现

在Application/TodoList下新建DeleteTodoList文件夹，并新建DeleteTodoListCommand：

DeleteTodoListCommand.cs

using MediatR;

using TodoList.Application.Common.Exceptions;

using TodoList.Application.Common.Interfaces;

namespace TodoList.Application.TodoLists.Commands.DeleteTodoList;

public class DeleteTodoListCommand : IRequest

{

    public Guid Id { get; set; }

}

public class DeleteTodoListCommandHandler : IRequestHandler<DeleteTodoListCommand>

{

    private readonly IRepository<Domain.Entities.TodoList> _repository;

    public DeleteTodoListCommandHandler(IRepository<Domain.Entities.TodoList> repository)

    {

        _repository = repository;

    }

    public async Task<Unit> Handle(DeleteTodoListCommand request, CancellationToken cancellationToken)

    {

        var entity = await _repository.GetAsync(request.Id);

        if (entity == null)

        {

            throw new NotFoundException(nameof(TodoList), request.Id);

        }

        await _repository.DeleteAsync(entity,cancellationToken);

        // 对于Delete操作，演示中并不返回任何实际的对象，可以结合实际需要返回特定的对象。Unit对象在MediatR中表示Void

        return Unit.Value;

    }

}

在Controller中添加Delete的接口处理：

TodoListController.cs

// 省略其他...

[HttpDelete("{id:guid}")]

public async Task<ApiResponse<object>> Delete(Guid id)

{

    return ApiResponse<object>.Success(await _mediator.Send(new DeleteTodoListCommand { Id = id }));

}

这里可能值得强调的是关于EntityFrameworkCore中对于关联实体DELETE操作的处理方式：

打开Infrastructure/Migrations文件夹，我们可以在迁移领域实体的那次Migration生成的.Designer.cs文件中发现这样一段配置：

// 省略其他...

modelBuilder.Entity("TodoList.Domain.Entities.TodoItem", b =>

    {

        b.HasOne("TodoList.Domain.Entities.TodoList", "List")

            .WithMany("Items")

            .HasForeignKey("ListId")

            .OnDelete(DeleteBehavior.Cascade)

            .IsRequired();

        b.Navigation("List");

    });

可以看到在OnDelete中配置的是DeleteBehavior.Cascade行为模式，关于DeleteBehavior，可以参考Referential Constraint Action Options。实际上总共有七种可以设置的行为模式：

DeleteBehavior.Cascade
DeleteBehavior.NoAction
DeleteBehavior.Restrict
DeleteBehavior.SetNull
DeleteBehavior.ClientCascade
DeleteBehavior.ClientNoAction
DeleteBehavior.ClientSetNull

关于这七种DeleteBehavior，可以参考这篇博文：Entity Framework Core 关联删除，博主在其中进行了比较详细的实验和总结。

可以根据实际需要去显式地配置DeleteBehavior。另外，习惯观察生成的Migrations文件，也是学习EFCore一些惯例或者说默认配置的很好的方法。

验证

启动Api项目，发送DELETE请求：

请求
响应

并且从数据库里我们以可以发现，这条TodoList下包含的TodoItem也被一同删除了。

总结

到此为止HTTP常用的四大请求我们已经通过几个例子讲完了，关于HEAD请求OPTION请求以及遗留的PATCH请求后面会写完。下一篇文章开始我们一起学习如何使用FluentValidation来进行请求参数校验。

关于HTTP请求幂等性的介绍

首先明确两个概念：

什么叫做HTTP请求是否安全：如果我们执行请求后，对应的资源实体不发生改变，我们称这个请求是安全的；
什么叫做HTTP请求是否幂等：对于执行请求后产生的副作用（即指如果请求不安全，则称其会产生副作用），请求执行一次和执行多次的副作用是相同的，我们称这个请求是幂等的，很显然安全的请求一定是幂等的。

了解了这两个概念后，我们直接来看这张表格，快速地对HTTP请求的安全性和幂等性有一个认识。

HTTP方法	是否安全？	是否具有幂等性？
GET	是	是
POST	否	否
PUT	否	是*
DELETE	否	是
OPTIONS	是	是
HEAD	是	是
PATCH	否	否

鉴于PATCH方法并不常用，那么重点需要关注的主要就是POST请求，以及一部分的PUT请求（比如更新的字段是在当前字段值的基础上进行计算而新得出这种场景，实际就不是幂等的，但是我们一般不推荐在Update时做这种类型的操作，更推荐的是把计算逻辑前置到接口响应处理前，以整体设置值的方式去Update实体）。一般而言POST请求是用来创建资源的，如果不采取某种方式来保证执行结果的实际幂等性，那么该请求产生的副作用将是难以控制和处理的。

如何保证接口的幂等性？

正式因为并非所有的HTTP请求（在这里我们可以泛化到任意类型的接口请求）都是幂等的，而不管是应用程序内的容错还是服务之间因为分区导致的对请求的幂等性更为严格的要求（尤其是在分布式系统中，对于分区导致的请求重试的场景），我们需要在设计和实现接口的时候，把幂等性设计考虑进来，提高接口的鲁棒性。

总体来说，实现接口的幂等性有两种思路：一种是通过代码逻辑去限制重复调用出现的副作用；第二种是通过Token唯一性来保证同一个请求不会被调用多次。

通过代码逻辑去限制副作用的实现方式有很多种：从前端/界面的层次上去人为限制请求的重复发送（比如按钮置灰禁止点击之类的），通过在数据库层面应用锁或使用唯一索引，通过在逻辑执行过程中应用锁等方式。这种方式只能针对一些通过满足某些判断进行的逻辑实现，有其局限性。

通过Token唯一性保证幂等的思路大致是这样：生成全局唯一的Token保存下来，并在前端页面获取保存，发送请求时连同Token一起发到后端，后端先进行Token校验，校验通过发送实际请求或执行逻辑，完成后删除旧Token并生成新Token，那么前端下次携带保存的旧Token来请求时，因为Token校验不通过而拒绝继续执行。这种方式就好比短信验证码，只有第一次携带这个验证码请求时会成功，后端判断第一次请求有效后就会把这个验证码置为无效，下次你就无法携带相同的验证码继续发起请求了。例子不是特别恰当，但是可以类比着进行理解。

参考资料