.NET 6开发TodoList应用之实现DELETE请求与HTTP请求幂等性

目录
  • 需求
  • 目标
  • 原理与思路
  • 实现
  • 验证
  • 总结

需求

先说明一下关于原本想要去更新的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请求幂等性的介绍

首先明确两个概念:

1.什么叫做HTTP请求是否安全:如果我们执行请求后,对应的资源实体不发生改变,我们称这个请求是安全的;

2.什么叫做HTTP请求是否幂等:对于执行请求后产生的副作用(即指如果请求不安全,则称其会产生副作用),请求执行一次和执行多次的副作用是相同的,我们称这个请求是幂等的,很显然安全的请求一定是幂等的。

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

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

如何保证接口的幂等性?

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

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

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

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

到此这篇关于.NET 6开发TodoList应用之实现DELETE请求与HTTP请求幂等性的文章就介绍到这了,更多相关.NET 6实现DELETE请求与HTTP请求幂等性内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • .NET 6开发TodoList应用之使用AutoMapper实现GET请求

    目录 需求 目标 原理与思路 实现 引入AutoMapper 实现GET请求 验证 获取所有TodoList列表 获取单个TodoList详情 填一个POST文章里的坑 总结 需求 需求很简单:实现GET请求获取业务数据.在这个阶段我们经常使用的类库是AutoMapper. 目标 合理组织并使用AutoMapper,完成GET请求. 原理与思路 首先来简单地介绍一下这这个类库. 关于AutoMapper 在业务侧代码和数据库实体打交道的过程中,一个必不可少的部分就是返回的数据类型转换.对于不同的

  • .NET 6开发TodoList应用之使用MediatR实现POST请求

    目录 需求 目标 原理与思路 CQRS模式 中介者Mediator模式 MediatR 实现 引入MediatR 实现Post请求 验证 创建TodoList验证 创建TodoItem验证 总结 参考资料 需求 需求很简单:如何创建新的TodoList和TodoItem并持久化. 初学者按照教程去实现的话,应该分成以下几步:创建Controller并实现POST方法:实用传入的请求参数new一个数据库实体对象:调用IRepository<T>完成数据库的写入,最多会在中间加一层Service.

  • .NET 6开发TodoList应用引入数据存储

    目录 一.需求 二.目标 三.原理和思路 四.实现 1. 引入Nuget包并进行配置 2. 添加DBContext对象并进行配置# 3. 配置文件修改 4. 主程序配置 5. 本地运行MSSQL Server容器及数据持久化 五.验证 一.需求 作为后端CRUD程序员(bushi,数据存储是开发后端服务一个非常重要的组件.对我们的TodoList项目来说,自然也需要配置数据存储. 目前的需求很简单: 需要能持久化TodoList对象并对其进行操作: 需要能持久化TodoItem对象并对其进行操作

  • .NET 6开发TodoList应用引入第三方日志库

    目录 1.需求 2.目标 3.原理和思路 4.实现 4.1日志配置实现 4.2主程序配置 4.3注入使用 5.验证 1.需求 在我们项目开发的过程中,使用.NET 6自带的日志系统有时是不能满足实际需求的,比如有的时候我们需要将日志输出到第三方平台上,最典型的应用就是在各种云平台上,为了集中管理日志和查询日志,通常会选择对应平台的日志SDK进行集成.使用Serilog提供的多种Sink,可以实现将日志写入不同云平台或者是非云平台的日志存储中去,这是我们这篇文章讲要研究的内容. 2.目标 我们将为

  • .NET 6开发TodoList应用之实现PUT请求

    目录 需求 目标 原理与思路 实现 PUT请求 领域事件的发布和响应 验证 总结 需求 PUT请求本身其实可说的并不多,过程也和创建基本类似.在这篇文章中,重点是填上之前文章里留的一个坑,我们曾经给TodoItem定义过一个标记完成的领域事件:TodoItemCompletedEvent,在SaveChangesAsync方法里做了一个DispatchEvents的操作.并且在DomainEventService实现IDomainEventService的Publish方法中暂时以下面的代码代替

  • .NET 6开发TodoList应用之实现Repository模式

    目录 需求 目标 原理和思路 实现 通用Repository实现 引入使用 验证 总结 需求 经常写CRUD程序的小伙伴们可能都经历过定义很多Repository接口,分别做对应的实现,依赖注入并使用的场景.有的时候会发现,很多分散的XXXXRepository的逻辑都是基本一致的,于是开始思考是否可以将这些操作抽象出去,当然是可以的,而且被抽象出去的部分是可以不加改变地在今后的任何有此需求的项目中直接引入使用. 那么我们本文的需求就是:如何实现一个可重用的Repository模块. 长文预警,

  • .NET 6开发TodoList应用之实现全局异常处理

    目录 需求 目标 原理和思路 实现 验证 总结 参考资料 需求 因为在项目中,会有各种各样的领域异常或系统异常被抛出来,那么在Controller里就需要进行完整的try-catch捕获,并根据是否有异常抛出重新包装返回值.这是一项机械且繁琐的工作.有没有办法让框架自己去做这件事呢? 有的,解决方案的名称叫做全局异常处理,或者叫做如何让接口优雅地失败. 目标 我们希望将异常处理和消息返回放到框架中进行统一处理,摆脱Controller层的try-catch块. 原理和思路 一般而言用来实现全局异

  • .NET 6开发TodoList应用实现结构搭建

    目录 1.TodoList需求简介 2.开发工具 2.1.NET 6 2.2Visual Studio Code 2.3Hoppscotch 3.Clean Architecture简介 4.搭建解决方案结构 5.运行 往期学习: .NET 6开发TodoList应用实现系列背景 1.TodoList需求简介 首先明确一下我们即将开发的这个TodoList应用都需要完成什么功能,我不会一次性把所有的特性诸如允许用户登陆之类的需求全部写上,只是先列出最基本的功能性需求: 我们可以维护一个TodoL

  • .NET 6开发TodoList应用实现系列背景

    目录 1.列说明 2.系列导航 2.1 使用.NET 6开发TodoList应用文章索引 2.1.1创建项目 2.1.2.NET 6 WebAPI Program.cs的变更 2.1.3Change 1: Top-level statements 2.1.4Change 2: Implicit using directives 2.1.5Change 3: No Startup class 2.2 关于Pipeline的一些知识点 2.2.1Pipeline Sequence 2.2.2app.

  • .NET 6开发TodoList应用之实现DELETE请求与HTTP请求幂等性

    目录 需求 目标 原理与思路 实现 验证 总结 需求 先说明一下关于原本想要去更新的PATCH请求的文章,从目前试验的情况来看,如果是按照.NET 6的项目结构(即只使用一个Program.cs完成程序初始化),那微软官方给出的文档目前还没有对应地更新,按照之前的方式进行JsonPatch的配置是不行的,目前已经有人在Github微软的官方文档Repo下提了ISSUE: .NET 6: JsonPatch in ASP.NET Core web API.并且因为PATCH的使用频率并不高,所以我

  • .NET 6开发TodoList应用实现系列背景

    目录 1.列说明 2.系列导航 2.1 使用.NET 6开发TodoList应用文章索引 2.1.1创建项目 2.1.2.NET 6 WebAPI Program.cs的变更 2.1.3Change 1: Top-level statements 2.1.4Change 2: Implicit using directives 2.1.5Change 3: No Startup class 2.2 关于Pipeline的一些知识点 2.2.1Pipeline Sequence 2.2.2app.

  • 使用.NET 6开发TodoList应用之引入数据存储的思路详解

    需求 作为后端CRUD程序员(bushi,数据存储是开发后端服务一个非常重要的组件.对我们的TodoList项目来说,自然也需要配置数据存储.目前的需求很简单: 需要能持久化TodoList对象并对其进行操作: 需要能持久化TodoItem对象并对其进行操作: 问题是,我们打算如何存储数据? 存储组件的选择非常多:以MSSQL Server/Postgres/MySql/SQLite等为代表的关系型数据库,以MongoDB/ElasticSearch等为代表的非关系型数据库,除此之外,我们还可以

  • 使用.NET 6开发TodoList应用之领域实体创建原理和思路

    需求 上一篇文章中我们完成了数据存储服务的接入,从这一篇开始将正式进入业务逻辑部分的开发. 首先要定义和解决的问题是,根据TodoList项目的需求,我们应该设计怎样的数据实体,如何去进行操作? 长文预警!包含大量代码 目标 在本文中,我们希望达到以下几个目标: 定义领域实体: 通过数据库操作领域实体: 原理和思路 虽然TodoList是一个很简单的应用,业务逻辑并不复杂,至少在这个系列文章中我并不想使其过度复杂.但是我还是打算借此简单地涉及领域驱动开发(DDD)的基础概念. 首先比较明确的是,

随机推荐