因为本套课程使用Maven包管理工具构建，所以在集成SwaggerCodegen时我们需要如下两个步骤：
这里我将依赖放到了下方，同学们可以直接拷贝：
我们知道，SwaggerCodegen主要的作用，就是生成服务端和客户端的完整代码文件，所以，在将SwaggerCodegen集成到SpringBoot中后，我们首先需要做的就是，对生成服务端和客户端的代码进行规则配置，即我们都需要生成什么样的服务端和客户端代码。
配置服务端和客户端的代码生成规则叫繁琐，所以我们选择常用的几个属性来进行演示。
swagger:'2.0'info:title:IMoocSwagger-WikiAPIdescription:Swagger-WikiAPIversion:1.0.0paths:/imooct/wiki/swagger:get:tags:-wikioperationId:getImoocLessonparameters:-name:rangein:querytype:stringrequired:true-name:lessonNamein:querytype:stringrequired:true-name:lessonTypein:querytype:stringresponses:'200':description:OKschema:$ref:'#/definitions/GetImoocLessonResponse'default:description:defaultschema:$ref:'#/definitions/ErrorResponse'对于以上所使用的属性我们会在本节的后半部分进行详细介绍，这里大家可以先做简单的了解即可。
{"apiPackage":"com.imooc.wiki.swagger.api","artifactId":"cmp-imooc-steafan-service","basePackage":"com.steafan.imooc.server","configPackage":"com.steafan.imooc.server.config","dateLibrary":"java8","delegatePattern":true,"groupId":"com.steafan.imooc","hideGenerationTimestamp":true,"java8":true,"language":"spring-boot","modelPackage":"com.imooc.wiki.swagger.api"}代码解释：
完成上述配置之后，我们就可以使用SwaggerCodegen来生成服务端和客户端代码。
在将SwaggerCodegen的依赖引入到SpringBoot中去后，我们就可以使用Maven自带的命令来将上述配置信息分别生成服务端和客户端代码，命令如下：
首先，将上述配置好的文件利用SwaggerCodegen来生成服务端和客户端代码
java-jarswagger-codegen-cli.jargenerate-iswagger.yaml-cswaggerConfig.json-lspring-oserver代码解释：
第一行，使用generate命令来将配置在swagger.yaml文件中的服务端代码进行生成。
第一行，使用-c参数，表明使用json配置文件，并且该配置文件的名称为swaggerConfig.json。
第二行，使用-l参数，表明客户端所使用的语言为spring。
第二行，使用-o参数来指定代码最终的存放位置，server表示将生成的代码存放到名为server的文件夹下。
然后我们使用cd命令来进到我们生成代码后所存放的目录：
cdserver最后我们将生成的代码打成Jar包:
mvnpackage这是Maven自带的打包命令，执行该命令之后，Maven会默认读取项目中的pom文件中配置的打包规则，即packaging节点，如果该节点没有配置任何规则，则Maven会默认打成Jar包(这里我们配置了Jar)。
这样我们就可以在项目的target目录下，找到我们利用SwaggerCodegen所生成的服务端和客户端代码的Jar包了，我们可以把该Jar包放到其他环境中使用，也可以供其他项目使用，这就是我们利用SwaggerCodegen所生成的服务端和客户端代码的最终使用目的。
我们针对以上服务端配置的规则来介绍一下在SwaggerCodegen服务端中经常使用的一些属性，同学在了解了这些属性之后就可以使用SwaggerCodegen进行一些服务端代码的生成工作了。
swagger:'2.0'info:title:IMoocSwagger-WikiAPIdescription:Swagger-WikiAPIversion:1.0.0paths:/imooct/wiki/swagger:get:tags:-wikioperationId:getImoocLessonparameters:-name:rangein:querytype:stringrequired:trueresponses:'200':description:OKschema:$ref:'#/definitions/GetImoocLessonResponse'代码解释：
swagger:指名生成的服务端代码所使用的Swagger管理版本，这里只能写2.0。
info:表示SwaggerCodegen所生成的服务端代码的一些基本描述信息，上述包括title(头信息)、description(文档描述)、version(文档版本)。
paths:表示具体一个接口的路径信息。
tags:表示该接口所属的分组。
operationId:表示该接口的名称。
parameters:表示该接口中的参数信息，上述包括name(参数名称)、in(参数用途)、type(参数类型)、required(参数是否必传，true表示参数必传，默认为false)。
responses:表示该接口的返回信息，这里的200表示接口返回状态码，description代表当接口返回状态码为200时的状态码描述信息，schema中的ref属性统一表示当该接口返回200时重定向的地址或接下来要发生的动作。
针对SwaggerCodegen中客户端代码的配置，在前面已经做了一些较为详细的介绍了，这里我就常用的客户端配置代码给上述内容做一个补充，同学们需要结合着来了解。
{"apiPackage":"com.imooc.wiki.swagger.api","artifactId":"cmp-imooc-steafan-service","groupId":"com.steafan.imooc","hideGenerationTimestamp":true,}代码解释：
apiPackage:表示需要生成的客户端代码的包位置。
artifactId、groupId:类似于Maven中的依赖坐标，这里表示所生成的客户端代码的坐标信息。
我们在生成服务端代码时，不能盲目生成，如果已经有写好的接口文档，那么我们需要按照这个接口文档进行编写和配置，如果没有写好的接口文档，那么我们需要和产品经理进行都次反复的沟通之后才能开始编写和配置服务端信息，这样可以在很大程度上减少服务端配置文件修改的次数，同时也可以提高服务端生成代码的准确性，这点同学们需要注意。
本小节从在SpringBoot中如何集成SwaggerCodegen出发，详细介绍了如何在SpringBoot中将SwaggerCodegen进行集成，以及在集成中容易出现的问题。在介绍完SwaggerCodegen集成SpringBoot之后，针对零基础的同学，老师将在SwaggerCodegen中使用的最多的属性单独拿出来做了介绍，旨在帮助同学们能够快速入门SwaggerCodegen。
各位同学在学习本小节内容时，希望各位可以跟着老师的节奏一行一行地把本小节中所将的代码都动手敲一下，这样可以加深自己对代码的理解程度，在实操时我们不能眼高手低，自己的实践结果才是最重要的。
大家好，今天为大家介绍SwaggerEditor。SwaggerEditor和SwaggerCodegen不同，SwaggerEditor适用于一切规模的项目，话不多说，咱们直入正题。
什么是SwaggerEditor呢？在Swagger官网中是这么介绍的：
SwaggerEditor是一个开源编辑器，我们可以在这个开源编辑器上设计、描述和记录我们的API信息，通过SwaggerEditor这个开源编辑器进行配置而生成的API是符合RESTFULAPI规范的，并且SwaggerEditor这款开源编辑器支持Swagger2.0版本和RESTFULAPI3.0版本。—官网
注意：这里提到的OpenAPI其实就是我们所谓的RESTFULAPI规范，关于RESTFULAPI规范我们已经在Swagger简介这一小节中做了详细的介绍，有不清楚的同学可以到该小节了解，这里不再赘述。
通过上面的介绍，说白了，SwaggerEditor就是一款提供了可以直接设计、描述和记录项目中所有的接口为RESTFULAPI文档的开源编辑器，可以帮助我们提升项目开发效率。
那么我们为什么要使用SwaggerEditor呢？
对于任何规模大小的项目而言，无论是小项目还是大项目，都会涉及到项目接口的开发，而对于项目接口的管理，最常见的就是根据项目接口内容撰写项目接口文档，但是这种方式有一种显而易见的弊端。
当项目中接口开发的需求发生变化时，根据项目管理规范，我们需要首先修改之前撰写好的相应的接口文档，由于种种原因，导致我们的修改时机很慢而不能及时支撑该接口的修改交付工作，这就会产生冲突，就会不得已先进行接口的修改，后续再来修改接口文档了。
针对上述类似问题，如果我们使用SwaggerEditor来对接口进行维护，就会大大降低这种问题出现的概率。
SwaggerEditor提供了强大的配置文件类型，例如我们熟知的yml配置源文件和少数的json配置源文件，针对这两种配置文件，SwaggerEditor内置了丰富的RESTFULAPI属性，开发人员可以直接使用这些属性来描述项目中的接口信息，不需要专门再将接口修改为符合RESTFULAPI规范而发愁了。
在第一章中，当我们在项目中集成了Swagger框架之后，运行项目之后会为我们生成Swagger-ui界面，我们都知道这个界面还是相对美观一些的，我们也可以直接在这个界面上浏览接口和其他信息。
SwaggerEditor在配置好之后的生成界面几乎是和Swagger-ui界面是一模一样的，而且SwaggerEditor的生成界面允许我们边修改配置信息边查看修改结果，可以实时看到我们的修改结果。
这就表明，如果我们项目中的接口需求发生了变动，我们可以直接在SwaggerEditor中修改相应的配置信息，并且可以实时看到修改结果，这对开发人员来说是一个’福音’。
学习SwaggerEditor这个工具和SwaggerCodegen一样，需要大家真实开发过项目并且对项目进行过简单的配置，并且使用的是Java7或以上的JDK版本。
如果你是一名后端开发人员，那么相信你在学习SwaggerEditor时会信手拈来。
SwaggerEditor其实就是一款可以为项目中的接口生成RESTFULAPI规范界面的开源工具，其完善的RESTFULAPI生成机制和美观的界面显示效果可以在提升项目接口的维护效率的同时增强接口文档的交互性，这也是SwaggerEditor的核心魅力。
本节会为大家介绍如何在当下主流操作系统中安装SwaggerEditor开源API配置工具。
基于Node环境来安装SwaggerEditor，是SwaggerEditor官方推荐使用的第一种方式，通过Node来安装SwaggerEditor，无论是Windows系统还是OSX系统，都要求电脑中首先要有Node，如果你的电脑中还没有Node环境，那么请先安装Node。
我们使用一下命令来在Node环境中安装HttpServer服务器：
基于Docker环境来安装SwaggerEditor是SwaggerEditor官方提供的第二种方式，同样地，想在Docker中安装SwaggerEditor，需要电脑中首先要有Docker环境。
众所周知，Docker是一个容器服务，其是通过提供众多工具的镜像文件来将对应的服务集成到容器中，而且Docker官方整理了全球主流工具的镜像文件，并且将其放到了DockerHub上面。
所以，要想在Docker中安装SwaggerEditor，我们首先需要从Docker官方的DockerHub上面将SwaggerEditor的镜像文件拉取(下载)下来，在Docker容器中命令如下：
dockerpullswaggerapi/swagger-editor运行以上指令，等待SwaggerEditor的镜像文件拉取完毕。
在SwaggerEditor镜像拉取完毕之后，我们可以直接运行该镜像文件，如果运行成功，则表明SwaggerEditor在Docker环境中已经安装成功，运行SwaggerEditor镜像文件的命令如下：
dockerrun-d-p80:8080swaggerapi/swagger-editor代码解释：
dockerrun-d-p为固定写法，同学们目前不用知道表示什么意思，只需要知道这是运行镜像文件的固定命令即可。
80:8080表示将Docker容器中的SwaggerEditor服务映射到我们本机的80端口上，
swaggerapi/swagger-editor表明我们所运行的镜像文件的名称。
在运行SwaggerEditor服务时，如果已经提供了json文件，那么我们可以使用以下命令进行启动，从而修改该json文件：
dockerrun-d-p80:8080-v$(pwd):/tmp-eSWAGGER_FILE=/tmp/swagger.jsonswaggerapi/swagger-editor在运行上述指令后，我们等待SwaggerEditor镜像文件在Docker容器中运行完毕即可。
无论使用哪种环境安装的SwaggerEditor，检测安装是否成功的标志已经在上述内容中提及，接下来我们需要做的是访问我们已经安装并运行的SwaggerEditor服务。
一般而言，当我们的SwaggerEditor服务启动之后，可以通过以下方式来访问：
Tips:
5.小结
在安装SwaggerEditor时，由于用到了Node环境和Docker环境，所以需要同学们先了解一下上述环境的基本使用方法，这样才可以随心应手的使用SwaggerEditor。
因为本套课程使用Maven包管理工具构建，所以在集成之前需要我们先将SwaggerEditor的依赖引入到项目中去，但是很不幸，SwaggerEditor官方并没有提供对Maven的支持，所以我们就不能通过Maven的方式将SwaggerEditor集成进来。
难道就没有办法将SwaggerEditor与SpringBoot结合使用了吗？
俗话说，方法总比困难多，所以这里我们另辟蹊径，通过使用配置yml文件的方式将SwaggerEditor集成进来，话不多说，我们直入正题。
我们都知道，在SpringBoot项目中，一般的项目配置文件是如下图所示的applicaiton.properties文件：
applicaiton.properties文件是传统的项目配置文件，无论使用Spring的哪种框架，我们都可以在项目中使用applicaiton.properties文件，但是这种文件有一种弊端，就是我们项目的配置信息在该文件中显示的有点乱，不利于开发人员维护，通常一行配置语句会显得很长，降低了项目配置文件的可阅读性。
正如此，在经过时代变迁之后，终于迎来了YAML配置源文件的到来，YAML文件不单单只是一种平台上的配置源文件，他可以支持Java、Python、PHP等主流语言使用，并且各种语言平台都有对应的转换配置语法对应关系表，编写起来简单方便，且利于阅读。
将applicaiton.properties文件修改为YMAL配置源文件的方式非常简单，我们只需要将applicaiton.properties文件的后缀.properties修改为.yml就可以了。
在修改完之后，我们就不能使用applicaiton.properties文件的语法了，我们需要使用YMAL配置源文件的语法才行。
在集成SwaggerEditor到SpringBoot中时，为什么我们需要将SpringBoot项目的配置文件applicaiton.properties来修改成YAML配置源文件呢？这是因为我们的SwaggerEditor只支持以.yml文件格式结尾的配置文件来编写SwaggerEditor，这也是我一再强调YAML配置源文件的原因。
在修改好配置源文件之后，接下来我们需要编写配置源文件，并且在编写完配置源文件之后，我们需要将该配置源文件进行重命名，重命名的规则一般都是项目名称+SwaggerEditor+配置源文件版本号。
SwaggerEditor的配置源文件我们在SpringBoot集成SwaggerCodegen小节中做了简短的介绍：就是我们在配置SwaggerCodegen服务端代码生成规则那里的服务端代码其实就是SwaggerEditor配置源文件的一部分，也就是说SwaggerCodegen服务端的代码生成规则是通过SwaggerEditor配置源文件来实现的。
所以，在掌握了SwaggerEditor的基本语法和使用技巧之后，我们就可以在编写好SwaggerEditor配置源文件之后来生成我们项目的服务端代码，可谓是一举两得，这也是Swagger官方为我们所考虑的一方面。
接下来我们通过SwaggerEditor官方的Demo来为大家配置SwaggerEditor。
SwaggerEditor基本配置信息
paths:/pet:post:tags:-"pet"summary:"Addanewpettothestore"description:""operationId:"addPet"consumes:"application/json""application/xml"produces:"application/xml""application/json"parameters:in:"body"name:"body"description:"Petobjectthatneedstobeaddedtothestore"required:trueschema:$ref:"#/definitions/Pet"responses:"405":description:"Invalidinput"对于以上所使用的属性我们会在本节的后半部分进行详细介绍，这里大家可以先做简单的了解即可。
在配置好SwaggerEditor基本配置信息和SwaggerEditor接口配置信息之后，我们就可以在项目中生成Swagger-UI界面了。
接下来，我们针对上述SwaggerEditor配置源文件中的属性来为大家介绍每个属性都代表什么意思，都用来做什么，以及在使用SwaggerEditor时的一些使用技巧和注意事项。
swagger:指名所使用的Swagger管理版本，这里只能写2.0。
info:表示SwaggerCodegen所生成的Swagger-UI界面的一些基本描述信息，上述包括title(头信息)、description(文档描述)、version(文档版本)、termsOfService(服务团队)、contact(联系人)、license(协议或条款)。
host:表示生成的Swagger-UI所在的主机，即Swagger-UI界面生成之后是放在什么位置的。
basePath:表示访问Swagger-UI生成界面的具体路径。
tags:表示对Swagger-UI文档中的接口进行分组。
tags-description:对接口分组添加描述信息。
tags-externalDocs:指定接口分组额外的说明文档，这里没有指定。
tags-url:表示对该接口分组添加额外的描述信息地址。
由于篇幅有限，SwaggerEditor接口配置信息部分的属性介绍在SpringBoot集成SwaggerCodegen这一小节中有详细的说明，同学们可以去该小节了解。
我们在使用SwaggerEditor时，一般都是在没有借口文档的情况下进行，所以这就要求我们对接口所开展的业务有很清晰的了解才行。
在SwaggerEditor中，我们会对不同属性编写不同的描述信息，而涉及到名字的属性一定要注意，例如：title属性，在对这一类型属性进行描述时，我们应该根据项目需求文档来进行描述，不能自己随意起名字，只有按照项目需求文档来描述的SwaggerEditor属性才能说是准确的，是服务于当前项目的。
在集成SwaggerEditor时，还需要注意SwaggerEditor与SwaggerCodegen之间的共同点与不同点，注意区分和体会他们的应用场景和使用目的，这样在实际开发中才能根据不同场景来选择合适的工具来完成工作。
大家好，今天为大家介绍Swagger生态体系中的最后一部分内容-Swagger辅助工具。该部分内容主要介绍Swagger官方提供的辅助工具，他们分别是：Validator、Parser、Inflector。
本节主要内容如下：
什么是SwaggerValidator呢？在Swagger官网中是这么介绍的：
SwaggerValidator是一个Swagger验证器，用于验证你的Swagger文档。—官网
从图中我们可以看到，SwaggerValidator的显示界面非常类似于Swagger-UI的显示界面，风格和排版都很相似，那么我们应该怎么来用呢？
根据官方文档我们不难看出，SwaggerValidator就是一个校验Swagger文档的工具，那么我们应该怎么来用呢？
我们可以在上述截图中看到一个Validator字样的单词，在这个单词下放，是Swagger官方为我们提供的Swagger文档中接口请求规范，以及接口定义要求。
就是说，我们可以把我们编写的Swagger文档和SwaggerValidator官方校验界面做一个比较，看一下是否符合SwaggerValidator官方的要求，校验的范围就包括：接口请求定义是否符合规范、接口返回值是否符合规范等，而进行校验的方式就是通过对比Validator下的内容。
如果在校验后发现，我们的Swagger文档有部分内容不符合SwaggerValidator官方所展示的，那么我们就需要对这一部分进行修改，直至符合SwaggerValidator官方的要求才行。
什么是SwaggerParser呢？在Swagger官网中是这么介绍的：
SwaggerParser是可以将Java项目中的POJO文件都解析成符合OpenAPI规范的类，同时它也提供了一个简单的框架来将不同平台的POJO文件都转换为统一的Swagger对象，来使整个Swagger工具链变得可用。—官网
我们可以这样简单的理解：SwaggerParser是专门服务于POJO文件的一个工具包，他可以将来自不同平台中的不符合OpenAPI规范的POJO文件都解析成符合统一规范的格式，使得我们在任何平台上都可以正常的使用Swagger。
由于Maven官方提供了对SwaggerParser的支持，所以我们只要将SwaggerParser的Maven依赖引入到我们项目中去就可以使用了：
SwaggerInflector是可以使用Swagger规范去驱动一种API的实现，并且你拥有全部的权限在实现过程中进行修改。—官网
也就是说，SwaggerInflector是一款可以使用Swagger规范去生成符合Swagger规范的API工具，并且可以在实现过程中针对不符合规范的地方进行完全的修改，最后使之符合Swagger的规范。
由于SwaggerInflector的使用相对非常少，并且如果想使用SwaggerInflector，那么你的项目就必须使用一种框架才能将SwaggerInflector集成进去，这个框架就是Jersey。
关于Jersey，这里就不多说了，大家只需要这是一款小众框架就行了，现在没有完全被淘汰，还有很多小公司仍在使用。
那么，在将Jersey集成好之后，我们就可以在Jersey生成的web.xml文件中添加如下配置来使用SwaggerInflector了：
我们在学习SwaggerValidator、Parser、Inflector时一定要注意他们的适用场景，区分他们之间的共同点和不同点，在学习本节内容时自己可以动手实践一下，这样才能更好地掌握。
SwaggerValidator、Parser、Inflector这三款辅助工具的介绍作为Swagger整套课程体系的最后一节内容，老师从他们的不同使用业务场景出发，介绍了他们最简单的使用方法，希望通过本节内容的介绍，同学们可以对这三款辅助工具有一个新的认识。
同学们，写到这里，Swagger系统知识点就给各位介绍完毕了，在这中间感谢各位的支持，江湖路远，我们有缘再见！