openapi回调地址请求不通过_如何实现 OpenAPI 多语言 SDK 开发？

阿里妹导读：由于每个网关所对应的后端情况不同，因此没有一套元数据可以适用于所有的网关。阿里云通过重新定义一门 DSL 语言 —— Darabonba 来支持不同风格的 OpenAPI，同时支持多语言的 SDK、Code Sample 目标生成。本文将从技术原理和解决方案分享相关的探索和实践。

文末推荐：OpenAPI 开发者挑战赛。

如今 OpenAPI 已经成为完成系统之间集成的重要桥梁，OpenAPI 的可用性以及用户在使用时的体验就变得越来越重要，阿里云前架构师曾说过："阿里云的本质是一家卖 API 的公司。API 有没有做好，是关乎生死的大事"。但是从日常来自用户的反馈中我们总结了以下比较通用的几点 OpenAPI 体验问题：

• 云产品 OpenAPI 没有提供 SDK 或者 SDK 语言不全；

• 部分云产品的 SDK 使用风格差异过大，导致使用成本增加；

• API 文档缺失或者不够清晰，不具备指导意义；

• 没有场景化 Code Sample 或提供 CodeSample 无法运行。

多语言 SDK 生成 说起生成多语言 SDK，大家第一时间想起的一定是当前业界内生成多语言 SDK 的通用方案——Swagger，开发者通过 Swagger 定义的 OpenAPI 标准并配合模板的方式来生成多语言 SDK。不过问题并没有因此而得到完美的解决。首先模版的生成方式相对生硬，虽然实现起来容易，但维护起来却不那么灵活；其次，大量 OpenAPI 并不是 RESTful 风格的，这就导致很多产品现存的 OpenAPI 在文档、SDK 等场景下，无法使用上 Swagger 这样强大的生态工具链。既然无法沿用 Swagger 规范元数据的方法来解决这个问题，我们就需要对我们的工作重新进行抽象。在笔者看来，之所以没有一套元数据可以适用于所有的网关主要还是因为每个网关所对应的后端情况不同，就像机器语言或者汇编语言会因为架构的不同而有所不同，但是其本质还是描述如何通过操作寄存器、内存里的数据来完成一个程序，高级语言就是通过 AST 兼容了各平台的这些不同最后解决了这些问题。而对于 OpenAPI 来说也是同样的道理，所以我们通过重新定义一门 DSL 语言 Darabonba 来描述各种各样的 OpenAPI。 通过 Darabonba 对 OpenAPI 进行描述，其本质就是统一了元数据，只是这个元数据并不是 JSON 或者 Yaml 这样的方式来描述的，而是通过 DSL 代码来描述。Darabonba 的编译器则会将 Darabonba 的 DSL 代码转化为 AST，通过 OpenAPI 描述转化而来的 AST 不仅包含了 OpenAPI 的信息，而且还包含整个 OpenAPI 的流程性描述，所以我们只需要通过 AST 开发对应的各语言SDK就可以生成多语言的 SDK了。Darabonba 具体的设计思路和理念可参考文章：Darabonba：支持任意 OpenAPI 网关的多语言 SDK 方案，这里就不再赘述。 模块化设计 在通过元数据向生成 SDK 的过程中，仅仅通过对 OpenAPI 的数据模型和请求/响应描述是不够的，还需要各种参数处理，签名生成，文件上传