欢迎关注公众号 《小姐姐味道》 ,一起进步!

# Swagger生成了几百兆的文档,该转移阵地了?

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

流年不利流年不利啊。项目写的太傻,庞大到生成了几百兆的Swagger文档。 通常,有个几兆就到了忍受极限了,这直接爆出几百兆。

问题源于这么一篇文章:小技巧:SpringBoot项目如何让前端开发提高效率? (opens new window)。其中提到使用swagger可以让前端、后端、QA、产品互动起来,很多研发已经用了。但有些项目生成的文章忒TM大了(抱歉我控制不住),在让这些项目愉快的go die之前,还是得想办法处理呀。

# 接口减肥

第一就是过滤减肥。 看一下你的Controller里写的是不是

@RequestMapping

这个注解将会生成7条api信息。 GET、HEAD、POST、PUT、DELETE、OPTIONS、PATCH

如果你能够确定调用方法,比如GET,请将注解改成

@GetMapping

# 不要有循环引用

返回的实体,还有请求的参数,不要循环引用。请干掉这些代码,不要邋遢,设计一点干净的api。

# 转线下

另一种思路就是把这些api都给捣鼓到线下,倒入到一个统一的地方进行管理。 这些也已经有很多产品了,比如Rap、Nei、YApi。

拿YApi来说(支持源码搭建),可以输入相应swagger的地址,进行一次导入,就可以将api定义转到另一个平台了。

YApi还有权限管理功能,应该是这里面做的最Nice的了。如果你想要统一管理、内网隔离,推荐一试。好东西,就不多介绍了。

# 结尾

转到线下虽然解决了因为api过大造成的服务不稳定,但api的更新同步会是另外一个问题。

不管采用何种方式,合理简洁的api设计是首要的。调用方法固定,不循环引用,最重要的,记得分模块哦。


作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,​进一步交流。​


关注回复 技术 关键字 ,即可 获取 海量资源

鲁ICP备2020043359号-1