Rust与其他语言跨FFI交互的模型管理最优方案问询

我目前正在开发一个完全用Rust编写的库，但该库将被Rust以外的编程语言调用。跨FFI边界通信已实现，但编写与Rust模型1:1映射的其他语言模型难度较大。本文旨在探寻是否存在工具或最佳实践，以简化跨FFI边界的模型生成工作。

我当前的实现方案如下：

• 所有跨FFI边界通信所需的模型均支持Serde序列化。
• 所有extern函数接收字符串指针并返回字符串指针。
• 函数调用传入JSON序列化后的参数字符串，返回JSON序列化后的响应字符串，这意味着客户端语言需要拥有与Rust模型序列化行为完全一致的模型集合。

如背景所述，跨FFI边界通信虽简单，但编写与Rust模型完全映射（且序列化一致）的模型却十分困难。目前我的Rust库已有5种不同编程语言的包装器，这些DTO模型的编写、测试与迭代过程繁琐复杂。

• 是否存在合理的方式描述库导出的模型与函数，以便通过工具生成模型或至少生成最小包装器？
• 通过FFI边界传输JSON是否存在问题？
• 是否存在我未了解的最佳实践或解决方案？

• Protocol Buffers：我曾尝试用Protocol Buffers替代JSON与手写模型，但该方案存在两大问题，不适用于我的场景：
  • Protocol Buffers缺少我需要的部分基础类型，例如8位整数、16位整数和128位整数类型。我希望强制某些类型限制为8位，且生成的模型应使用目标语言中的8位整数类型。
  • Protocol Buffers默认所有字段为可选，无法设置为必填。虽然这适用于大多数应用，但我开发的库更倾向于在运行时panic而非处理可选字段的默认值。
• Cap'n'proto：该方案存在与上述类似的问题，强制所有字段为可选，不符合我的需求。
• OpenAPI：我曾尝试用OpenAPI schema描述所有模型，供客户端语言生成模型，但存在以下问题：
  • OpenAPI代码生成器生成的模型往往可读性差、无法编译，且难以理解与迭代。

内容的提问来源于stack exchange，提问作者RustInterop