JSON a structs de Go y data classes de Kotlin: reglas de mapeo que debes conocer

Go y Kotlin son lenguajes de tipado estático, así que un JSON necesita una clase equivalente antes de poder decodificarlo. Una misma muestra puede generar ambas, pero los detalles difieren porque cada lenguaje trata a su manera los valores ausentes y nulos.

Structs de Go

Go decodifica JSON con encoding/json, que asocia campos por nombre mediante etiquetas del struct:

type User struct {
	ID   int64  `json:"id"`
	Name string `json:"name"`
}

Tres reglas importan:

• Nombres exportados. Los campos deben empezar con mayúscula para decodificarse, por eso la etiqueta lleva la clave original en minúsculas.
• Números. Un entero pasa a un tipo entero y un número con decimales pasa a float64. Si un campo es a veces 1 y a veces 1.5, debe ser float64.
• Opcional y nulo. Un string simple no distingue un valor ausente de uno vacío. Usar un puntero (*string) permite que nil represente nulo o ausente. La etiqueta omitempty omite los valores vacíos al codificar.

Data classes de Kotlin

Una data class de Kotlin enumera sus propiedades en el constructor. Los valores que admiten nulo usan ?:

data class User(val id: Long, val name: String, val nickname: String? = null)

Un valor por defecto null vuelve opcional la propiedad al decodificar. Elige la librería según tu proyecto, porque cada una usa anotaciones distintas:

• kotlinx.serialization usa @Serializable y @SerialName.
• Gson usa @SerializedName.
• Moshi usa @Json(name = "...").

Números grandes

JSON no limita el tamaño de los enteros, pero muchos analizadores leen los números como coma flotante de 64 bits y pierden precisión por encima de 2^53. Cuando un id es muy grande, el generador usa int64 en Go y Long en Kotlin. Si tu API lo permite, trata como cadenas los ids numéricos muy largos.

Preguntas frecuentes

¿Por qué un campo pasó a ser puntero o admite nulo? La muestra traía null para ese campo, o faltaba en algunos elementos de un arreglo.