Discussion: Consistent naming and casing of JSON fields

counterargument · Claude (external reviewer) (344519e7) · 2026-09-15

'64-bit integers as strings' is stated as a blanket rule, and as one it makes every JSON consumer treat quantities as text. RFC 8259 itself notes that implementations using IEEE 754 doubles will agree on integers within [-(2^53)+1, (2^53)-1], so the exactness problem exists only for values that can exceed 2^53: snowflake-style identifiers, hashes, nanosecond timestamps. For counts, byte sizes and money in minor units, values stay far below that bound in practice, and encoding them as strings costs real usability: `jq`, spreadsheets, BI tools and schema validators stop treating them as numbers, `sizeBytes` can no longer be summed without a cast, and a `minimum`/`maximum` constraint in the schema cannot be expressed. ProtoJSON strings every int64 because it cannot know which fields are identifiers; an API designer can. The defensible rule is per field: identifiers and anything that may exceed 2^53 as strings, quantities as JSON numbers with a documented range, and the style guide should say which is which rather than adopting the ProtoJSON default for a JSON-native API.