玩转API
快速开启 - ApiHug如何在15分钟内，使用 ApiHug 启动一个API开发项目.
https://apihug.com/zhCN-docs/start
📐设计先行
通过统一的API 设计元语(DSL, domain specific language), 让API 设计更语言化（Describe)；实现高度的一致化，和高复用。
📑协议驱动
OAS (OpenAPI specification), 是 ApiHug世界的 "金科玉律", 严格保证定义 ↔ 实现之间同构(isomorphism)态射。
🗺️单一信任源
实现 API 从：蓝图→施工→测试→落地，不走样， 不变形，不改味。极致沟通效率和极低信任成本。
❤️ 开发同理心
置身于多种角色,感同身受，在快和慢，现在和将来,个体和团队上综合平衡，极具同理心是ApiHug 人文基础，她不仅仅是一段代码，一个工具，一种方式。
Kola
大家都知道我要对测试下手了 :-), 在考察了九九八十二个方案后在放弃的边缘前(一入测试深似海,不如继续去搬砖)， 只能舍弃和妥协， 因为我们需要：
简单，超级简单；do not make me learning!
傻瓜，超级傻瓜，人人都能懂(业务方也能写，最后是模型给写), do not make me thinking
不会(容易)犯错，想犯错也不行
效率高，易维护
DSL, 静态校验；大家都知道我对DSL 比较推崇
IDE 支持(或者低成本改造)
通用，和 1&2对应
高度模块化、复用， 给老板们省钱
各种人员友好
.....
最终选择了：
BDD 风格(标准)
Groovy DSL
java poet 定义动态代码
junit5 + rest-assured + assertj + json-path+wiremock 底座
为什么？
spring cloud contact 太难理解了，团队学习成本太高
karate ：IDEA 支持居然要钱，脚本用js 引擎，不符合java 范
cucumber： 嗯， 还有很多需要处理，实现和定义分裂
spock： 要点习惯迁移
此方案的优点：
学习成本低
BDD 范能保留
接近java语法
模块化
测试用例正规化管理
服务端测试， 客户端mock 一并解决(spring cloud contract记大功)
缺点
Java poet 需要学习==但是spring 也是用poet生成代码的哦，所以不怕
要效率更近一层，需要稍微改造IDEA：模版和语法提示，小case
需要配套使用，否则威力大减
支持中间件：MQ, DB,CACHE,UI,Perf,异步 etc
是不是很期待呢？
