Formatear JSON

JSON—JavaScript Object Notation—es el formato ubicuo basado en texto para el intercambio de datos estructurados. Está estandarizado tanto por la IETF como RFC 8259 y por Ecma International como ECMA-404, que juntos definen la sintaxis compacta e independiente del idioma que impulsa las API, los registros, las configuraciones y las bases de datos modernas.

Sintaxis y codificación: los bits precisos que mantienen los sistemas en comunicación

Un valor JSON es un objeto, array, cadena, número, o uno de los literales true, false, o null; los objetos asignan cadenas a valores y los arrays contienen valores ordenados, con espacios en blanco insignificantes permitidos alrededor de los caracteres estructurales (RFC 8259, ECMA-404). Aunque JSON se originó en JavaScript, es independiente del idioma y es compatible prácticamente en todas partes (MDN: JSON). En la transmisión, la codificación de facto y recomendada es UTF-8 (RFC 8259 §8.1). Para mayor seguridad de interoperabilidad, el perfil I-JSON (RFC 7493) endurece las reglas sobre codificaciones y rangos numéricos.

En JavaScript, el objeto global JSON expone dos caballos de batalla:JSON.parse (con un reviver opcional) y JSON.stringify (con reemplazador/espaciado para una impresión bonita), como se documenta en MDN (parse, stringify).

Números: engañosamente simples, sorprendentemente afilados

La gramática numérica de JSON es decimal, pero la especificación no dicta la precisión ni las distinciones entre enteros y flotantes. Las implementaciones eligen cómo representarlos (RFC 8259 §6). En JavaScript y Node.js, Number es de doble precisión IEEE-754, lo que significa que solo los enteros en [−(2^53−1), 2^53−1] son exactamente seguros; consulte Number.MAX_SAFE_INTEGER y el tipo BigInt. Es por eso que las API públicas a menudo envían los ID como cadenas y validan los "enteros seguros" explícitamente.

Más allá del JSON básico: punteros, parches y parches de fusión

A medida que maduró el uso, surgieron estándares para direccionar y modificar JSON en su lugar. JSON Pointer (RFC 6901) es una sintaxis diminuta delimitada por barras para localizar valores (p. ej., /a/b/0) con reglas de escape para ~ y /. JSON Patch (RFC 6902) modela actualizaciones parciales como operaciones ordenadas (add, remove, replace, move, copy, test) y viaja como application/json-patch+json. Para diferencias más simples, JSON Merge Patch (RFC 7386) utiliza una fusión con forma de documento: los campos presentes se agregan/reemplazan; establecer un campo en null lo elimina. Muchos frameworks admiten una o ambas formas de manera nativa.

Esquemas y tipos: validación y generación

JSON en sí mismo no tiene esquema, pero los ecosistemas se apoyan en esquemas para la validación, la documentación y la generación de código. La familia JSON Schema 2020-12 especifica restricciones como type, properties, items y palabras clave de composición, y se alinea con OpenAPI 3.1. Para flujos de trabajo centrados en la generación de código, JSON Type Definition (RFC 8927) ofrece un lenguaje deliberadamente menos expresivo que se asigna de manera predecible a los sistemas de tipos convencionales.

Streaming y big data: líneas y secuencias de JSON

El JSON clásico espera un texto completo por carga útil, lo que complica la transmisión de registros y las respuestas de larga duración. Dos patrones ayudan:

• Secuencias de texto JSON (RFC 7464): un flujo de textos JSON UTF-8, cada uno precedido por el Separador de registros (U+001E) y terminado con LF; registrado como application/json-seq.
• NDJSON / JSON Lines: cada línea es un valor JSON independiente, fácil de seguir, comprimir con gzip y map-reduce (ndjson.org, jsonlines.org). Es popular en las API masivas, p. ej., la API masivade Elasticsearch.

Primos binarios: cuando el texto no es lo suficientemente compacto

Cuando el ancho de banda o la velocidad dominan, los formatos "JSON binario" preservan el modelo de datos de JSON mientras cambian la legibilidad humana por la eficiencia:

• BSON (formato nativo de MongoDB) agrega tipos como binario, fecha y hora y enteros con tipo (bsonspec.org).
• MessagePack es compacto y sin esquema, ampliamente implementado en varios idiomas (msgpack.org).
• CBOR estandariza un formato extensible y compacto (con guía de transcodificación de JSON) y es común en contextos de IoT/restringidos (RFC 8949, cbor.io).
• Smile (del ecosistema Jackson) codifica JSON con referencias inversas opcionales para nombres/valores repetidos (jackson-dataformat-smile).

Notas de seguridad: viejos trucos y soluciones modernas

Debido a que JSON es solo texto, la mayoría de los riesgos provienen de cómo lo transporta y lo maneja:

• JSONP (solicitar datos a través de <script> con una devolución de llamada) fue una solución alternativa anterior a CORS para solicitudes de origen cruzado, pero es peligrosa: ejecuta scripts arbitrarios. Prefiera CORS con respuestas application/json reales (OWASP: Abuso de JSONP).
• Secuestro de JSON: los puntos finales GET ingenuos que devuelven matrices sensibles podrían ser robados a través de etiquetas de script de origen cruzado en navegadores más antiguos; las mitigaciones incluyen POST con protecciones CSRF o prefijar con un centinela que no sea JSON (OWASP: Secuestro de JSON).
• Inyección de JSON: trate a JSON como datos, no como código; escape diligentemente y valide las entradas (OWASP: Inyección de JSON).

Tipos de medios y herencia

JSON debutó bajo RFC 4627 (2006); el tipo de medio registrado es application/json, cuya especificación ahora apunta a RFC 8259. Los parámetros "charset" en las respuestas JSON son generalmente innecesarios porque UTF-8 es el predeterminado en la Internet pública.

Consejos prácticos para un JSON robusto en producción

• Use UTF-8 de forma predeterminada en todas partes; asuma UTF-8 en la entrada y la salida (RFC 8259 §8.1).
• Sea explícito con los enteros grandes: si un ID puede exceder 2^53−1, envíelo como una cadena y documéntelo (MDN: MAX_SAFE_INTEGER).
• Valide las cargas útiles con JSON Schema 2020-12 (o JTD para pilas pesadas en generación de código). Publique esquemas junto a la documentación de su API (OpenAPI 3.1).
• Use los parches con prudencia: use JSON Patch para diferencias a nivel de operación y Merge Patch para actualizaciones simples con forma de documento.
• Transmita a escala: elija Secuencias de texto JSON o NDJSON para registros y respuestas de larga duración; haga explícito el tipo de medio.
• Recurra a binario ( BSON, MessagePack, CBOR, Smile) cuando el texto sea el cuello de botella, pero asegúrese de que ambos extremos estén de acuerdo con los tipos.

Una breve palabra sobre los "JSON más amigables"

Los desarrolladores a menudo quieren comentarios, comas finales o cadenas entre comillas simples en las configuraciones. Eso está fuera del JSON estándar, pero JSON5 proporciona un superconjunto bien documentado para archivos editados por humanos. Evite enviar JSON5 a través de API públicas a menos que controle ambos extremos.

El éxito de JSON proviene de una superficie pequeña, un amplio soporte de idiomas y un anillo de estándares adyacentes (punteros, parches, esquemas, secuencias) que cubren las realidades desordenadas de los sistemas distribuidos. Comprenda los fundamentos (sintaxis, codificación, números), apóyese en los estándares adyacentes correctos y seguirá pagando dividendos en todas las pilas y servicios (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).