为何OpenAPI（JSON Schema）不支持无符号整数？哪些REST API规范支持？

为什么OpenAPI不原生支持32/64位无符号整数？ #

OpenAPI的设计逻辑和编程语言完全不同，你提到的编程语言无符号数支持的讨论偏向设计哲学，而OpenAPI的取舍核心来自两个现实约束：

• 底层依赖的JSON/JSON Schema标准本身没有原生无符号整数类型。JSON的number类型不区分符号、也不固定位宽，所有整数的符号、位宽约束都需要通过minimum、maximum这类附加字段间接定义，OpenAPI作为基于JSON Schema的上层规范，不会新增底层标准没有的原生基础类型。
• OpenAPI的核心设计目标是保障跨语言兼容性。目前仍有大量主流语言/运行时没有原生无符号整数支持：比如Java 8之前的版本完全没有无符号数实现，JavaScript的Number类型最大安全整数仅为2^53-1，无法无损存储64位无符号整数。如果OpenAPI强推原生无符号类型，会直接导致这部分场景的代码生成器出现兼容问题，违背了它降低跨语言对接成本的设计初衷。

所谓「规范要划定边界」的说法在这里是成立的，边界的判断标准不是类型普及度，而是该类型能否在所有OpenAPI覆盖的场景下做到无歧义、无额外兼容成本落地，无符号整数刚好卡在了跨语言兼容的门槛上。

如果确实需要在OpenAPI中描述无符号整数，行业通用的 workaround 是通过自定义格式实现，示例如下：

# uint64 类型定义
type: integer
format: uint64
minimum: 0
maximum: 18446744073709551615

只要你使用的代码生成器识别uint64这个自定义format，就能正常生成对应类型的客户端代码。

支持原生无符号整数的REST相关API规范 #

目前主流规范中，原生内置无符号整数类型的包括：

• gRPC/Protobuf：虽然gRPC是RPC框架，但其IDL原生支持uint32、uint64等无符号类型，配套的HTTP+JSON转码方案也能完整对应无符号数约束
• AsyncAPI：事件驱动场景的接口描述规范，在JSON Schema基础上扩展了原生无符号整数格式，直接支持uint32、uint64的标准format定义
• Smithy：AWS推出的接口定义规范，原生内置unsignedInteger、unsignedLong等无符号整数类型，专门适配云服务接口场景

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