何为正向，何为反向？ 举个例子：在数据库的设计里面这个概念可能被大量涉猎；古早先是 DBA设计好表以及表之间的关系(一对多，多对一，多对多...)；然后应用是通过ORM 映射数据库表到业务内领域对象；于是乎大量的数据库反向工程工具就应运而生，很多低代码平台就是这样操作的通过获取数据库schema的元信息，反向生成“智能”表格；新时代的 text2sql, chat2db 都是大致的操作思路；应用程序的质量第一保证在数据库设计， 笔者在职业生涯前期遇到很多大型金融系统里面的应用都是这么个架构，DBA 才是最吃香的， 应用层开发类似于现在的前端，提供一个友好的入口，大部分的业务逻辑在 DB 的存储过程， 有多达数千行的存储过程！

当然现在这部分逻辑大部分迁移到应用程序了， 某种意义上换了个地方挖坑，不过有更多从代码、架构甚至是产品上可操作空间，现代应用程序开发日趋成熟：语言、框架、人才&工程化。DBA 角色渐渐聚集到Paas类基础设施平台(瞎猜)，像笔者现在团队，多时有50+开发，有各种角色，就是没有独立的DBA。 开发在数据库应用实践上可以说比一些DBA 还熟练：如何优化索引，如何查看SQL Plan等等。

有反向工程就有正向工程， 言归正传到我们的API 设计开发的世界里，虽然各种工具都上了，开源的商业的；但是你发现团队里面 API 设计和实现始终是断层的， 连反向工程程度都达不到！

写、实现、测试API的人完全是"分裂"；设计阶段，迫于整个平台的规范，大家在一些API平台上写了API描述， 实现者如后台JAVA工程师，可“高保真”实现API,达到90%一致性，但不可避免开发中又"悄悄"和前端商量了个新API, 测试的人整了在线表格来誊写测试用例；就在这样一个 “分裂”的状态下，团队歪歪扭扭往前走着， 说不上来好和坏，但总归很是别扭。

更大的隐患，在往后旷日持久的升级更新过程中，多方各执一词，即使在同一个版本迭代不同环境API的细微差异都不能内部保持沟通一致，不满和扯皮在团队内蔓延！

API 作为一个应用对外的脸面，理应被"打扮"得漂漂亮亮，但往往面目全非、惨不忍睹；虽API只是应用的一个"副产品"， 但恰是分歧和混乱的最佳"指示灯"。

为什么绝大部分的API管理平台， 没有实现从API设计一步到位正向工程化到API实现呢？ 因为无法做到!!!

平台定位是大一统，就像再好的IDE 也不能帮你设计出NB的软件一样！

解决之道在于取舍， 在单个团队里面开发语言和框架基本是一定的，让放弃大一统成就小而美成为可能。

ApiHug 正是在限定范围内，为API正向工程化提供可能；提供专门为API设计的元语，设计 ⇋ 落地，实现双向可逆推导。

如果说现在市面上很多API平台是 “面子”工程， 那么ApiHug 就是您的“里子”工程，提升您的研发核心力量。 

API 设计工具千万家,ApiHug才是真的爱大家

💝 不玩心跳、擦边，只有实打实的爱！

⛔ 不是更强的 postman、jmeter, xxxx！

🥳 ApiHug 提供API 设计到实现的新范式!

ApiHug 准则：

1. 📐 设计先行：  Design First

2. 📑 协议驱动：Specification Driven

3. 🗺️ 单一信任源: Single Source of Truth

4. ❤️ 开发同理心: Development Empathy

ApiHug:

1. 无服务: 一切尽在本地， 或者您的内部 Repository

2. 无强依赖: 遵循行业最佳、最成熟实践、可插拔 

3. 无隐藏：一切尽公开透明

📐设计先行

通过统一的API 设计元语(DSL, domain specific language), 让API 设计更语言化（Describe)；实现高度的一致化，和高复用。

📑协议驱动

OAS (OpenAPI specification), 是 ApiHug世界的 "金科玉律", 严格保证定义 ↔ 实现之间同构(isomorphism)态射。

🗺️单一信任源

实现 API 从：蓝图→施工→测试→落地，不走样， 不变形，不改味。极致沟通效率和极低信任成本。

❤️ 开发同理心

置身于多种角色,感同身受，在快和慢，现在和将来,个体和团队上综合平衡，极具同理心是ApiHug 人文基础，她不仅仅是一段代码，一个工具，一种方式。

We Build What We Love & Love What We Built

https://apihug.com/docs/start/what-is-apihug

开启愉快开发之旅：https://apihug.com/docs/start

00. 预安装

1. JDK 17+ OpenJDK or Oracle

2. Gradle 8+

3. IDEA 2022+

4. ApiHug - API design Copilot  IDEA plugin 市场

01. 插件安装

1. File

2. Settings

3. Plugin

4. Search ApiHug

5. Install & Restart

02. Project Wizard

ApiHug - API design Copilot 提供了一个非常友好的项目启动模板，按照步骤一路点下来就可以。

01- 开始ApiHug项目

1. File

2. New -> Project

3. ApiHug

02-项目设置

1. Project settings

2. package

3. name

4. description

5. SDK Settings

6. version

7. DB Vendor

8. Cache

9. Port

03-Spring 设置

标准Spring 配置和 starter.spring.io 一样:

1. 选择类型

2. 选择你需要的模块，比如： Spring Web

最后 点击： Create -> Open Project  就可以打开项目啦！

04-开启项目

跟着IDEA的引导:

1. 以 Gradle 方式加载项目, 如果没有检查通知Notification栏目,可能你隐藏了;

2. 两个模块 demo-app-proto & demo-app 应该被gradle自动识别出来。

04.1-Wire

1. 打开 README.md > 0. Build All

2. 找到那段脚本贴到控制台上： Terminal

3. 回车 Enter 执行

4. 检查模块 demo-app-proto 目录 main > wire 里面内容和更新

04.2-Stub

1. 打开 README.md > 2. Build Stub (Individual)

2. 同理找到那段命令行，贴到控制台 Terminal

3. 按回车 Enter 执行

4. 检查模块 demo-app 目录 main > stub 里内容和更新:

04.3-Boot

1. 打开 README.md > 3. Run Application

2. 找到对于命令，贴到 Terminal

3. 回车 Enter 执行

4. 检查命令行输出 Log demo-app

----------------------------------------------------------
Application 'demo-app' is running! Access URLs:
Local                             http://localhost:18089/External                          http://192.168.0.115:18089/OAS                               http://192.168.0.115:18089/v3/api-docsActuator                          http://192.168.0.115:18089/managementApi-Errors                        http://192.168.0.115:18089/hope/meta/errorsApi-Dictionaries                  http://192.168.0.115:18089/hope/meta/dictionariesApi-Authorities                   http://192.168.0.115:18089/hope/meta/authoritiesProfile(s)                        dev

04.4-查看 OAS

1. 从控制台命令行上找到对应的URL

2. 在浏览器(Chrome)输出查看即可 

ApiHug 工具栏

ApiHug 工具栏(Tool Window)  默认停靠在您的IDEA右侧栏, 当然您也可通过上面菜单调出 :   ApiHug > ApiHug Designer : 

🥳 恭喜! 开启您愉悦的开发之旅吧!