ASP.NET Core使用Swagger/OpenAPI规范

目录
  • 1.什么是Swagger/OpenAPI?
  • 2.NET Swagger实现
  • 3.Swashbuckle主要组成部分
  • 4.什么是REST?
  • 5.配置Swagger中间件
  • 6.XML注释
  • 7.数据注释

1.什么是Swagger/OpenAPI?

Swagger是一个与语言无关的规范,用于描述REST API。因为Swagger项目已捐赠给OpenAPI计划,所以也叫OpenAPI。它允许计算机和人员了解服务的功能,可以直接在线访问测试API方法。而Swagger UI提供了基于Web的UI,它使用生成的Swagger规范提供有关服务API的信息。Swashbuckle和NSwag均包含Swagger UI的嵌入式版本,因此可使用中间件注册调用将该嵌入式版本托管在ASP.NET Core应用程序当中。Swagger的核心是Swagger规范,默认情况下是名为swagger.json的文档。它由Swagger工具链(或其第三方实现)根据你的服务生成。它描述了API的功能以及使用HTTP对其进行访问的方式。它驱动Swagger UI,并由工具链用来启用发现和客户端代码生成。

2.NET Swagger实现

NET Swagger实现分为两大分类:

  • Swashbuckle.AspNetCore是一个开源项目,用于生成ASP.NET Core Web API的Swagger文档。
  • NSwag是另一个用于生成Swagger文档并将Swagger UI或ReDoc集成到ASP.NET Core Web API中的开源项目。此外,NSwag 还提供了为API生成C#和TypeScript客户端代码的方法。

但是由于工作比较忙,我就不打算两个类型都讲了,我只选择Swashbuckle.AspNetCore来讲解和演示。

3.Swashbuckle主要组成部分

Swashbuckle有三个主要组成部分:

  • Swashbuckle.AspNetCore.Swagger:将SwaggerDocument对象公开为JSON终结点的Swagger对象模型和中间件。
  • Swashbuckle.AspNetCore.SwaggerGen:从路由、控制器和模型直接生成SwaggerDocument对象的Swagger生成器。它通常与Swagger终结点中间件结合,以自动公开Swagger JSON。
  • Swashbuckle.AspNetCore.SwaggerUI:Swagger UI工具的嵌入式版本。它解释Swagger JSON以构建描述Web API功能的可自定义的丰富体验,它包括针对公共方法的内置测试工具。

安装Swashbuckle组件方法有两种:

--PowerShell
Install-Package Swashbuckle.AspNetCore -Version 5.0.0

or

--.NET Core CLI
dotnet add TodoApi.csproj package Swashbuckle.AspNetCore -v 5.0.0

4.什么是REST?

我百度一下,度娘解释是:REST是(Representational State Transfer)“表现层状态转移”的缩写,它是由罗伊·菲尔丁(Roy Fielding)提出的,是用来描述创建HTTP API的标准方法,他发现这四种常用的行为“查看(view),创建(create),编辑(edit)和删除(delete)”都可以直接映射到HTTP中已实现的GET、POST、PUT和DELETE方法。

5.配置Swagger中间件

将Swagger生成器添加到Startup.ConfigureServices方法中的服务集合中:

//注册Swagger生成器,定义一个或多个Swagger文档.
services.AddSwaggerGen(c =>
{
    c.SwaggerDoc("v1", new OpenApiInfo { Title = "My API", Version = "v1", Description = "测试描述" });
});

OpenApiInfo对象是用来标识Swagger文档信息(诸如作者、许可证和说明的信息),您还可以自定义您的主题的信息显示在UI上,详情配置,我就不多说,大家可以看官网描述,如上述OpenApilnfo信息配置示例图:

而在启动应用程序后并导航到http://localhost:<port>/swagger/v1/swagger.json。生成的描述终结点的文档显示在Swagger规范(swagger.json)中:

在Startup.Configure方法中,启用中间件为生成的JSON文档和Swagger UI提供服务:

//使中间件能够将生成的Swagger用作JSON端点.
app.UseSwagger();
//允许中间件为swagger ui(HTML、JS、CSS等)提供服务,指定swagger JSON端点.
app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1");
});

根据上述配置就能够启用swagger测试API服务接口了,如下图所示:

6.XML注释

swagger还可以把服务API中对应方法名称,实体属性注释给在UI上显示出来,让您更加直观了解每个方法使用信息,并对没有注释每个方法进行警告提示,具体启用XML注释操作在“解决方案资源管理器”中右键单击该项目,然后选择“编辑<project_name>.csproj”,手动将突出显示的行添加到.csproj 文件:

<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>

在启用了XML注释后,swagger只会针对没有添加注释每个方法进行警告提示,而添加了注释的方法则不会进行警告提示:

而每个添加了注释的方法会通过在Startup.ConfigureServices/services.AddSwaggerGen中设置Swagger JSON和UI的注释路径后:

//设置Swagger JSON和UI的注释路径.
var xmlFile = $"{Assembly.GetExecutingAssembly().GetName().Name}.xml";
var xmlPath = Path.Combine(AppContext.BaseDirectory, xmlFile);
c.IncludeXmlComments(xmlPath);

会在项目根目录生成的一个对应项目文件名的XML文件,而文件里面就包含所有已注释的方法,用于UI上显示:

在启动应用程序后,我们会看到每个有注释方法在左侧会有一行文字描述,效果如下图所示:

如果某个方法或者类下面所有方法不想警告提示,可以通过加入#pragma warning disable声明屏蔽警告提示:

加入声明之后,大家会看到警告提示消失了。

7.数据注释

可以使用System.ComponentModel.DataAnnotations命名空间中的属性来标记模型实体,以帮助驱动Swagger UI 组件。将[Required]属性添加到TodoItem类的Name属性:

namespace TodoApi.Models
{
    public class TodoItem
    {
        public long Id { get; set; }
        [Required]
        public string Name { get; set; }
        [DefaultValue(false)]
        public bool IsComplete { get; set; }
    }
}

此属性的状态会更改掉基础JSON架构:

而将[Produces("application/json")]属性添加到API控制器去,这样做的目的是声明控制器的操作支持application/json的响应内容类型:

[Produces("application/json")]
[Route("api/[controller]")]
[ApiController]
public class ValuesController : ControllerBase
{
    /// <summary>
    /// 获取值
    /// </summary>
    /// <returns></returns>
    // GET api/values
    [HttpGet]
    public async Task<ActionResult<IEnumerable<string>>> Get()
    {
        var result = await new GitHubApi().GetUser();
        return new string[] { result.id.Value.ToString(), result.login };
    }
}

“响应内容类型”下拉列表选此内容类型作为控制器的默认GET操作:

Swagger/OpenAPI出现,大大减少开发者调试时间,增加开发者开发效率,让开发者更加方便调试跟直观了解对应服务方法。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • ASP.NetCore使用Swagger实战

    踩坑不背锅,.NET Core 试深浅 关于Swagger什么是swagger所带来的帮助 使用Swagger 关于Swagger 什么是swagger 使人和计算机在看不到源码或者看不到文档或者不能通过网络流量检测的情况下能发现和理解各种服务的功能. Swagger™ 的目标是为 REST APIs 定义一个标准的,与语言无关的接口.只需要按照它的规范去定义接口及接口相关的信息.再通过Swagger衍生出来的一系列项目和工具,就可以做到生成各种格式的接口文档,生成多种语言的客户端和服务端的代码

  • Asp.Net Core WebAPI使用Swagger时API隐藏和分组详解

    1.前言 为什么我们要隐藏部分接口? 因为我们在用swagger代替接口的时候,难免有些接口会直观的暴露出来,比如我们结合Consul一起使用的时候,会将健康检查接口以及报警通知接口暴露出来,这些接口有时候会出于方便考虑,没有进行加密,这个时候我们就需要把接口隐藏起来,只有内部的开发者知道. 为什么要分组? 通常当我们写前后端分离的项目的时候,难免会遇到编写很多接口供前端页面进行调用,当接口达到几百个的时候就需要区分哪些是框架接口,哪些是业务接口,这时候给swaggerUI的接口分组是个不错的选

  • asp.net core 3.0中使用swagger的方法与问题

    Intro# 上次更新了 asp.net core 3.0 简单的记录了一下 swagger 的使用,那个项目的 api 比较简单,都是匿名接口不涉及到认证以及 api 版本控制,最近把另外一个 api 项目升级到了 3.0,还是遇到了一些问题,这里单独写一篇文章介绍,避免踩坑. Swagger 基本使用# swagger 服务注册: services.AddSwaggerGen(option => { option.SwaggerDoc("sparktodo", new Ope

  • ASP.NET Core中使用Swagger

    一.什么是Swagger 随着技术的不断方法,现在的网站开发基本都是使用前后端分离的模式,这样使前端开发者和后端开发者只需要专注自己擅长的即可.但这种方式会存在一种问题:前后端通过API接口的方式进行调用,接口文档的好坏可以决定开发的进度.以前如果使用Word的形式提供接口文档,或多或少的都会存在各种问题.前端抱怨说后端给的接口文档与实际情况不一致.而后端开发人员又觉得编写以及维护接口文档很费精力,文档经常不能及时更新,导致前端看到的还是旧的接口文档.这时候就需要使用Swagger了. 那么什么

  • 记Asp.Net Core Swagger使用并带域接口处理的方法

    引用作者原话:Asp.Net的WebApi中使用Swagger作为说明和测试的页面是非常不错的,比起WebApiTestClient来至少在界面上的很大的提升.但是使用Swagger时如果只是一般的控制器直接放到Controller下就可以了,而如果因不同的业务需求而需要分类或者有同名的类名时时则没办法很好的处理. 因为业务需求需要创建域,但是Swagger并未将域添加到接口.所以需要加上以下操作才行. 安装Swagger方法: 为了大家多看微软官方文档.就直接引用Swagger安装及使用方法.

  • .NetCore使用Swagger+API多版本控制的流程分析

    目录 一.Swagger基本使用 二.Swagger结合版本控制 本文实例环境及版本.NetCore3.1.Swagger6.1 现在的开发大部分都是前后端分离的模式了,后端提供接口,前端调用接口.后端提供了接口,需要对接口进行测试,之前都是使用浏览器开发者工具,或者写单元测试,再或者直接使用Postman,但是现在这些都已经out了.后端提供了接口,如何跟前端配合说明接口的性质,参数等这也是一个问题.有没有一种工具可以根据后端的接口自动生成接口文档,说明接口的性质,参数等信息,又能提供接口调用

  • Asp.net core WebApi 使用Swagger生成帮助页实例

    最近我们团队一直进行.net core的转型,web开发向着前后端分离的技术架构演进,我们后台主要是采用了asp.net core webapi来进行开发,开始每次调试以及与前端人员的沟通上都存在这效率低下的问题,一次在看微软asp.net core官方文档的时候,发现了swagger这个好东西.然后在实际的项目中引入了该技术.我们开发人员测试自己写的api的过程大大得到了简化,前端人员也可以根据我们提供的swagger help pages 自己进行一些前端代码的测试,大大提高了前后端的开发效

  • .NET Core利用swagger进行API接口文档管理的方法详解

    一.问题背景 随着技术的发展,现在的开发模式已经更多的转向了前后端分离的模式,在前后端开发的过程中,联系的方式也变成了API接口,但是目前项目中对于API的管理很多时候还是通过手工编写文档,每次的需求变更只要涉及到接口的变更,文档都需要进行额外的维护,如果有哪个小伙伴忘记维护,很多时候就会造成一连续的问题,那如何可以更方便的解决API的沟通问题?Swagger给我们提供了一个方式,由于目前主要我是投入在.NET Core项目的开发中,所以以.NET Core作为示例 二.什么是Swagger S

  • Asp.Net Core使用swagger生成api文档的完整步骤

    前言 .Net Core中有两个集成NSwag的包,分别为Swashbuckle和NSwag.两者的配置大同小异.这里以NSwag为例. 一.前期准备 1.初始化asp.net core 测试项目 新建asp.net core项目,此处略过: 新建apicontroller,并编写测试代码: [Route("api/[controller]")] [ApiController] public class UserApiController : ControllerBase { ///

  • asp.net core 集成swagger ui的原理解析

    什么是Swagger? 说swagger 之前,我们先说一下OpenApi 规范. OpenApi 是一种和语言无关的用于描述RESTAPIs 接口功能的一种规范,对RESTAPIs 接口的描述包括: 接口参数信息.接口返回值信息.api 功能描述.请求路径等. 这里我们说OpenApi 只是一种规范,既然是一种规范,就必然有相应的实现,Swagger 就是其中一个实现了Open Api 规范的工具. .net 中RESTAPIs的代表便是 web api ,并且.net 针对Web Api 也

随机推荐