如何通过Swagger实现API文档的优化与提升？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1842个文字，预计阅读时间需要8分钟。
背景：.NET 6 已发布已久，但公司项目因多种原因仍基于 .NET Framework。
内容：随着版本迭代，后端 API 接口不断增加，每次联调时，前端开发叫苦不迭。
背景 尽管.net6已经发布很久了，但是公司的项目由于种种原因依旧基于.net Framework。伴随着版本迭代，后端的api接口不断增多，每次在联调的时候，前端开发叫苦不迭：“小胖，你们的swagger页面越来越卡了，快优化优化！”。
先查看swagger页面加载耗时：
以上分别是：
- v1加载了两次
- 重新编译程序后打开swagger页面，加载v1（api json）竟然耗时两分多钟。
- 第一次完整加载页面后重新刷新页面，再次查看swagger的耗时，这次明显页面加载速度提升了不少，但依旧不尽人人意，json返回后渲染耗时太久。
swagger加载的卡慢问题，萌生了优化swagger的想法，刚开始按传统技能在网络上搜索了一大圈依旧未找到解决方案。幸好swashbuckle开源，还能自己动手分析了。先下载好源码GitHub - domaindrivendev/Swashbuckle.WebApi: Seamlessly adds a swagger to WebApi projects!
一、先看看v1加载慢，却要加载两次。
从上面的图上不难发现第二次v1的加载是跟在lang.js后面，而lang.js实际上就是用来做汉化。打开项目中这个文件
原来是为了添加控制器注释，重新访问后端取一次接口文档。
本文共计1842个文字，预计阅读时间需要8分钟。
背景：.NET 6 已发布已久，但公司项目因多种原因仍基于 .NET Framework。
内容：随着版本迭代，后端 API 接口不断增加，每次联调时，前端开发叫苦不迭。
背景 尽管.net6已经发布很久了，但是公司的项目由于种种原因依旧基于.net Framework。伴随着版本迭代，后端的api接口不断增多，每次在联调的时候，前端开发叫苦不迭：“小胖，你们的swagger页面越来越卡了，快优化优化！”。
先查看swagger页面加载耗时：
以上分别是：
- v1加载了两次
- 重新编译程序后打开swagger页面，加载v1（api json）竟然耗时两分多钟。
- 第一次完整加载页面后重新刷新页面，再次查看swagger的耗时，这次明显页面加载速度提升了不少，但依旧不尽人人意，json返回后渲染耗时太久。
swagger加载的卡慢问题，萌生了优化swagger的想法，刚开始按传统技能在网络上搜索了一大圈依旧未找到解决方案。幸好swashbuckle开源，还能自己动手分析了。先下载好源码GitHub - domaindrivendev/Swashbuckle.WebApi: Seamlessly adds a swagger to WebApi projects!
一、先看看v1加载慢，却要加载两次。
从上面的图上不难发现第二次v1的加载是跟在lang.js后面，而lang.js实际上就是用来做汉化。打开项目中这个文件
原来是为了添加控制器注释，重新访问后端取一次接口文档。