【遥遥领先】Eolink IDEA 插件：零代码入侵，自动生成接口

[Eolink开发者社区]

省流版：

Eolink 有 IDEA 插件吗？

有，而且遥遥领先！我们在一年半之前就发布了，而且功能更丰富！

IDEA 插件市场搜索“Eolink Apikit”即可安装使用。

🚀使用指引：https://plugins.jetbrains.com/plugin/19189-eolink/jie-shao

前不久用户群内有热心用户发出了这样的一个疑问“建议开发一个零代码入侵的，自动生成接口的 Idea插件 "

某个 潜水窥屏 深入调研用户需求的产品经理看到后一惊，居然还有开发同学不知道 Eolink 是国内首家上线 IDEA 插件的商业平台？😢

😢都怪我们，跟华为一样不开发布会就把插件上线了。Eolink 的 IDEA 免费插件 早在 2022 年 3 月就已经上线 IDEA 插件市场了，至今早有一年半的时间了，我们的产研团队一直默默更新，忘记告诉大家了。

今天给大家重新详细地介绍一下 Eolink Apikit 的 IDEA 插件能力~

Eolink 自 2016 年发布以来,就一直在 API 全生命周期管理领域深耕。在整个全生命周期的流程中，首要解决的问题是如何基于已有的历史数据转成标准规范的 API 文档，并在统一的文档仓库中管理起来。

Eolink 很早前就提供多种生成 API 文档的方式了：

1. 手工录入或导入对应协议文件

支持 HTTP / Websocket / TCP / UDP / HSF / Dubbo / gRPC / SOAP等

2. 导入其他 API 管理平台数据

支持 Postman / Swagger / Jmeter / Yapi / ApiDoc / HAR / RAP / Apipost / Apifox / ShowDoc 等

3. 基于 Swagger URL 一键同步

4. 基于 git 仓库 URL 一键同步

支持 gitlab / github / gitee 等

5. 基于数据库表生成

支持 MySQL / Oracle / Redis / SQL Server / MongoDB / PostgreSQL / AnalyticDb / MariaDB 等

以上的这些生成 API 文档方式能适配大部分用户的使用场景，对于项目初期或者进行大规模数据迁移时也十分好用。但是在项目接口迭代过程中，这些方法就显得有点“笨重”。

对于开发同学来说，无论是新增还是修改接口文档，都需要在开发工具和接口管理工具上同步最新的数据。而且接口文档变更内容会比较琐碎和频繁。那么是否有更轻便的同步接口数据方式呢？

我们提供了一个高效方案：
在开发工具上基于接口代码片段，一键生成 API 文档，支持在开发工具中调试，并可一键上传至 Eolink Apikit 的代码仓库中。

这样不仅可以减少界面的操作和系统间的切换，还可以在开发工具上完成琐碎和频繁的接口文档更新，是当前 CODE TO API 的最佳实践。

如上图的业务流程展示，后端工程师其所有任务均可通过 IDEA 插件在 IDEA 开发工具中完成，无需跨系统跨平台，满足频繁零散更新的场景。

在传统的 CODE TO API 场景下，就无法不聊 Swagger 提供的解决方案了。Swagger 通过预先填写代码注解，然后再通过解析，实现了代码生成API文档的能力。那么对比 Swagger ，Eolink Apikit 的 IDEA 插件又有什么优势呢？ 

1. 核心区别是无代码侵入

Eolink Apikit 插件与 Swagger 最大的差异在于代码侵入性上。Swagger 的运行机制决定了其需要通过在代码文件中编写注解、配置、描述等信息才能生效，一定程度上会对代码产生侵入性的影响。

Eolink Apikit 提供的 IDEA 插件方案是可通过 Java 文件的方法出入参进行解析，自动生成 API 文档的。也就是说可以在不填写任何的注解的情况下，使用 Eolink 的插件生成 API 文档。

2. 兼容多种注解，自动补全

毕竟 Swagger 是全球热门的传统 API 管理工具，部分旧代码可能已经编写了 Swagger 注解，对于这些注解 Eolink Apikit 插件也会进行兼容，作为解析接口能力的重要补充信息。

除了对 Swagger 的 V2 版本和 V3 版本注解支持外，我们还支持 Spring MVC 注解、 JavaDoc注释、Eolink注释和Dubbo注解，使得插件的适配场景更广。

如果现有的注释不全，插件还会根据对Java文件的分析，自动生成注释进行补全。

3. 更全面的协议支持

Swagger 一般仅支持 HTTP 协议，而 Eolink Apikit 插件除了支持 HTTP 协议外，还支持 Dubbo 和 HSF 协议的上传。并且后续会逐步拓宽支持更多协议类型。
 

从 2021 年开始，API 管理领域出现了一些新的优秀工具，最近一年也有很多用户希望了解 Eolink Apikit 与市面上其他同类产品能力区别。本文把对比的范围控制在插件能力给大家一个参考，Eolink Apikit 的 IDEA 插件优势在哪里？ 

 

🚀 全自研插件能力更适配

Eolink Apikit 的 IDEA 插件是完全自研的，于 2022 年 3 月 19 日上线。

插件研发的缘由最早是 Eolink 内部某研发线的后端同学自己编写的一些脚本，然后团队投入大量人力进行补全优化成插件，并内部运行稳定后上架到插件市场的。经过一年半的时间，Eolink 的 IDEA 插件已经获得超过 17万下载量（IDEA 市场同类插件下载量排名第一），其稳定性、业务适配能力已经过大量的企业级开发团队使用和验证。

经过调研，我们可以发现市面同类产品的插件均是通过“开源插件改造”或者“开源+用户共创”的模式研发而来的。虽然这种开发模式能够很大程度上节省研发成本以及插件的研发时间。但是开源插件与自生平台的兼容性问题是不可避免的。

 

开源插件落后能力 与 IDEA 插件新体系 的矛盾冲突：

同类插件基本都是从开源插件“easy-api”进行改造上线的，但是使用“esay-api”改造的插件会面临一个核心问题是拓展能力差。

📌划重点：

easy-api 开源插件是 18 年发布的第一个版本，并在 19 年 9 月份推出正式版本。而 IDEA 插件体系在 2020 年则进行了一次大革新，大部分核心接口都进行了调整并支持了更多新的能力。

所以用 2020 年前的接口能力来做的“esay-api”插件本身就很难支持更多的能力拓展和更好的使用体验。我们可以发现“开源魔改”这类型插件一直在改善和优化原开源插件的兼容性问题，这点可以从同类插件的历史更新记录上得到印证。

 

为什么我们坚持全自研 IDEA 插件？

与开源插件改版而来的 IDEA 插件相比，原生自主研发的插件在拓展能力和兼容能力会更胜一筹，同时也避免了插件能力与业务场景不适配的问题。

相对采用开源改版的开发模式而言，纵使全自研前期的研发成本会更大，从 0 开始会更加难，Eolink Apikit 仍然选择走完全自主研发的产品策略。IDEA插件的每一行代码都倾注了研发团队心血，使得我们的插件可以提供更多的服务和场景能力，真正地帮助开发者用户提升 API 研发效能。

我们把同类 IDEA 插件产品在 IDEA 插件市场的相关数据整理如下：

 

Eolink Apikit 的 IDEA 插件上线时间最早，用户验证最多，并且代码完全自主研发，在业务适配能力上有充足公正的第三方平台可视化数据证明， Eolink Apikit 的 IDEA 插件早已在私有化交付中使用，已被多个研发规模超 10000 人的企业客户验证。

 

🎉 功能多样更强大

目前市面上同类插件提供能力比较接近 Swagger，更多的仅仅调整了上传到对应平台的能力；而 Eolink Apikit 不满足于此，我们提供了更多样的能力支持：

零注解生成：目前同类插件还需要编写注解才能生成 API 文档，无法支持零注解生成，以及自动生成注释的能力。

RPC类型接口生成：Eolink Apikit 支持 Dubbo 和 HSF 的协议接口生成，后续还会逐步支持更多接口协议。

注释拓展：为了支持更多自定义的场景，Eolink Apikit 插件提供了更多业务拓展注释，可以在设置界面添加自定义注释或兼容现有注释。

多种上传方式：Eolink 关注开发者更多的使用场景，提供完整项目级别扫描上传、新接口定义上传、接口部分变更属性上传等多种不同层级的上传方式，使用更便捷更随心所欲。

 Eolink Apikit 的 IDEA 插件，是国内商业平台中最早发布的 API 管理插件，代码完全自主研发，功能多样且安全稳定。

希望经过本文，可以让大家了解我们“未开发布会先上线”的 IDEA 插件，最后，Eolink Apikit 提供的插件是免费的，更多安装使用说明可以查阅：https://plugins.jetbrains.com/plugin/19189-eolink/jie-shao