JSON

Notación de objetos de JavaScript

El logotipo JSON es una banda de Möbius
Extensión de nombre de archivo	.json
Tipo de medio de Internet	aplicación/json
Código de tipo	TEXTO
Identificador de tipo uniforme (UTI)	público.json
Tipo de formato	Intercambio de datos
Extendido desde	JavaScript
Estándar	Norma 90 ( RFC  8259), ECMA-404, ISO/IEC 21778:2017
¿ Formato abierto ?	Sí
Sitio web	json.org

JSON ( JavaScript Object Notation , pronunciado / ˈdʒeɪsən / o / ˈdʒeɪˌsɒn / ) es un formato de archivo estándar abierto y un formato de intercambio de datos que utiliza texto legible por humanos para almacenar y transmitir objetos de datos que consisten en pares atributo-valor y matrices (u otros valores serializables ). Es un formato de datos de uso común con diversos usos en el intercambio electrónico de datos , incluido el de aplicaciones web con servidores .

JSON es un formato de datos independiente del lenguaje . Se derivó de JavaScript , pero muchos lenguajes de programación modernos incluyen código para generar y analizar datos en formato JSON. Los nombres de archivo JSON usan la extensión .json.

Douglas Crockford especificó originalmente el formato JSON a principios de la década de 2000. ^[1] Él y Chip Morningstar enviaron el primer mensaje JSON en abril de 2001.

El estándar internacional de 2017 (ECMA-404 e ISO/IEC 21778:2017) especifica que "JSON" se "pronuncia /ˈdʒeɪ.sən/ , como en 'Jasón y los Argonautas ' " . [ 2 ] [ 3 ] La primera ^{edición ( 2013} ) de ECMA-404 no abordó la pronunciación. ^[4] El Manual de administración de sistemas UNIX y Linux afirma : " Douglas Crockford , quien nombró y promovió el formato JSON, dice que se pronuncia como el nombre Jason. Pero de alguna manera, 'JAY-sawn' ^[a] parece haberse vuelto más común en la comunidad técnica". ^[5] Crockford dijo en 2011: "Hay mucha discusión sobre cómo se pronuncia eso, pero estrictamente no me importa". ^[1]

Después de que RFC  4627 estuviera disponible como su especificación "informativa" desde 2006, JSON se estandarizó por primera vez en 2013, como ECMA -404. ^[4] RFC  8259, publicada en 2017, es la versión actual del estándar de Internet STD 90, y sigue siendo coherente con ECMA-404. ^[6] Ese mismo año, JSON también se estandarizó como ISO / IEC 21778:2017. ^[2] Los estándares ECMA e ISO / IEC describen solo la sintaxis permitida, mientras que RFC cubre algunas consideraciones de seguridad e interoperabilidad. ^[7]

JSON surgió de la necesidad de un protocolo de comunicación de sesión de servidor a navegador en tiempo real sin utilizar complementos de navegador como Flash o applets de Java , los métodos dominantes utilizados a principios de la década de 2000. ^[8]

Crockford fue el primero en especificar y popularizar el formato JSON. ^[1] El acrónimo se originó en State Software, una empresa cofundada por Crockford y otros en marzo de 2001. Los cofundadores acordaron construir un sistema que utilizara las capacidades estándar de los navegadores y proporcionara una capa de abstracción para que los desarrolladores web crearan aplicaciones web con estado que tuvieran una conexión dúplex persistente a un servidor web manteniendo abiertas dos conexiones de Protocolo de transferencia de hipertexto (HTTP) y reciclándolas antes de que se agotaran los tiempos de espera estándar de los navegadores si no se intercambiaban más datos. Los cofundadores tuvieron una mesa redonda y votaron sobre si llamar al formato de datos JSML (lenguaje de marcado de JavaScript) o JSON (notación de objetos de JavaScript), así como bajo qué tipo de licencia hacerlo disponible. El sitio web JSON.org ^[9] se lanzó en 2001. En diciembre de 2005, Yahoo! comenzó a ofrecer algunos de sus servicios web en JSON. ^[10]

Un precursor de las bibliotecas JSON se utilizó en un proyecto de juego de intercambio de activos digitales para niños llamado Cartoon Orbit en Communities.com ^{[ cita requerida ]} (los cofundadores de State habían trabajado todos en esta empresa anteriormente) para Cartoon Network ^{[ cita requerida ]} , que utilizó un complemento del lado del navegador con un formato de mensajería propietario para manipular elementos DHTML (este sistema también es propiedad de 3DO ^{[ cita requerida ]} ). Tras el descubrimiento de las primeras capacidades de Ajax , digiGroups, Noosh y otros utilizaron marcos para pasar información al campo visual de los navegadores del usuario sin actualizar el contexto visual de una aplicación web, logrando aplicaciones web enriquecidas en tiempo real utilizando solo las capacidades estándar HTTP, HTML y JavaScript de Netscape 4.0.5+ e Internet Explorer 5+. Crockford luego descubrió que JavaScript podía usarse como un formato de mensajería basado en objetos para dicho sistema. El sistema se vendió a Sun Microsystems , Amazon.com y EDS .

JSON se basó en un subconjunto del lenguaje de programación JavaScript (específicamente, Standard ECMA -262 3rd Edition—December 1999 ^[11] ) y se usa comúnmente con JavaScript, pero es un formato de datos independiente del lenguaje . El código para analizar y generar datos JSON está disponible en muchos lenguajes de programación . El sitio web de JSON enumera las bibliotecas JSON por lenguaje.

En octubre de 2013, Ecma International publicó la primera edición de su estándar JSON ECMA-404. ^[4] Ese mismo año, RFC  7158 utilizó ECMA-404 como referencia. En 2014, RFC  7159 se convirtió en la referencia principal para los usos de JSON en Internet, reemplazando a RFC  4627 y RFC  7158 (pero conservando ECMA-262 y ECMA-404 como referencias principales). En noviembre de 2017, ISO/IEC JTC 1/SC 22 publicó ISO/IEC 21778:2017 ^[2] como estándar internacional. El 13 de diciembre de 2017, el Grupo de Trabajo de Ingeniería de Internet dejó obsoleto RFC  7159 cuando publicó RFC  8259, que es la versión actual del Estándar de Internet STD 90. ^{[12] [13]}

Crockford añadió una cláusula a la licencia JSON que establecía que "el software se utilizará para el bien, no para el mal", con el fin de convertir en código abierto las bibliotecas JSON y, al mismo tiempo, burlarse de los abogados corporativos y de aquellos que son demasiado pedantes. Por otra parte, esta cláusula provocó problemas de compatibilidad de la licencia JSON con otras licencias de código abierto, ya que el software de código abierto y el software libre normalmente no implican restricciones en cuanto al propósito de uso. ^[14]

El siguiente ejemplo muestra una posible representación JSON que describe a una persona.

{ "nombre" : "John" , "apellido" : "Smith" , "está vivo" : verdadero , "edad" : 27 , "dirección" : { "dirección de la calle" : "21 2nd Street" , "ciudad" : "Nueva York" , "estado" : "NY" , "código postal" : "10021-3100" }, "números de teléfono" : [ { "tipo" : "casa" , "número" : "212 555-1234" }, { "tipo" : "oficina" , "número" : "646 555-4567" } ], "hijos" : [ "Catherine" , "Thomas" , "Trevor" ], "cónyuge" : null }                                          

Aunque Crockford afirmó originalmente que JSON es un subconjunto estricto de JavaScript y ECMAScript , ^[15] su especificación en realidad permite documentos JSON válidos que no son JavaScript válido; JSON permite que los terminadores de línea Unicode U+2028 LINE SEPARATOR y U+2029 PARAGRAPH SEPARATOR aparezcan sin escape en cadenas entre comillas, mientras que ECMAScript 2018 y anteriores no lo hacen. ^{[16] [17]} Esto es una consecuencia de que JSON solo prohíbe los "caracteres de control". Para una máxima portabilidad, estos caracteres deben estar escapados por una barra invertida.

El intercambio de JSON en un ecosistema abierto debe estar codificado en UTF-8 . ^[6] La codificación admite el conjunto completo de caracteres Unicode, incluidos aquellos caracteres fuera del plano multilingüe básico (U+0000 a U+FFFF). Sin embargo, si se escapan, esos caracteres deben escribirse utilizando pares sustitutos UTF-16 . Por ejemplo, para incluir el carácter Emoji U+1F610 😐 NEUTRAL FACE en JSON:

{ "cara" : "😐" } // o { "cara" : "\uD83D\uDE10" }      

JSON se convirtió en un subconjunto estricto de ECMAScript a partir de la revisión del lenguaje de 2019. ^{[17] [18]}

Los tipos de datos básicos de JSON son:

• Número: un número decimal con signo que puede contener una parte fraccionaria y puede utilizar la notación exponencial E, pero no puede incluir números que no sean números, como NaN . El formato no hace distinción entre números enteros y de punto flotante. JavaScript utiliza el formato de punto flotante de doble precisión IEEE-754 para todos sus valores numéricos (posteriormente también admitió BigInt ^[19] ), pero otros lenguajes que implementan JSON pueden codificar los números de manera diferente.
• Cadena : una secuencia de cero o más caracteres Unicode . Las cadenas se delimitan con comillas dobles y admiten una sintaxis de escape con barra invertida .
• Booleano : cualquiera de los valores trueofalse
• Matriz : lista ordenada de cero o más elementos, cada uno de los cuales puede ser de cualquier tipo. Las matrices utilizan la notación de corchetes con elementos separados por comas.
• Objeto : una colección de pares nombre-valor donde los nombres (también llamados claves) son cadenas. El estándar ECMA actual establece que "la sintaxis JSON no impone ninguna restricción sobre las cadenas utilizadas como nombres, no requiere que las cadenas de nombres sean únicas y no asigna ningún significado al orden de los pares nombre/valor". ^[20] Los objetos se delimitan con llaves y se utilizan comas para separar cada par, mientras que dentro de cada par, el carácter de dos puntos ':' separa la clave o el nombre de su valor.
• null: un valor vacío, utilizando la palabranull

Se permiten y se ignoran los espacios en blanco alrededor o entre elementos sintácticos (valores y puntuación, pero no dentro de un valor de cadena). Cuatro caracteres específicos se consideran espacios en blanco para este propósito: espacio , tabulación horizontal , avance de línea y retorno de carro . En particular, la marca de orden de bytes no debe ser generada por una implementación conforme (aunque puede aceptarse al analizar JSON). JSON no proporciona sintaxis para comentarios . ^[21]

Las primeras versiones de JSON (como las especificadas en RFC  4627) requerían que un texto JSON válido consistiera únicamente en un objeto o un tipo de matriz, que podía contener otros tipos dentro de ellos. Esta restricción se eliminó en RFC  7158, donde un texto JSON se redefinió como cualquier valor serializado.

Los números en JSON son independientes de su representación en los lenguajes de programación. Si bien esto permite serializar números de precisión arbitraria42 , puede generar problemas de portabilidad. Por ejemplo, dado que no se hace ninguna diferenciación entre valores enteros y de punto flotante, algunas implementaciones pueden tratar , 42.0, y 4.2E+1como el mismo número, mientras que otras no. El estándar JSON no establece requisitos con respecto a los detalles de implementación, como desbordamiento , desbordamiento insuficiente , pérdida de precisión, redondeo o ceros con signo , pero sí recomienda no esperar una precisión mayor que la de IEEE 754 binary64 para una "buena interoperabilidad". No hay una pérdida de precisión inherente al serializar una representación binaria a nivel de máquina de un número de punto flotante (como binary64) en una representación decimal legible por humanos (como los números en JSON) y viceversa, ya que existen algoritmos publicados para hacer esto de manera exacta y óptima. ^[22]

Los comentarios se excluyeron intencionalmente de JSON. En 2012, Douglas Crockford describió su decisión de diseño de esta manera: "Eliminé los comentarios de JSON porque vi que la gente los estaba usando para contener directivas de análisis, una práctica que habría destruido la interoperabilidad". ^[21]

JSON no permite "comas finales", una coma después del último valor dentro de una estructura de datos. ^[23] Las comas finales son una característica común de los derivados de JSON para mejorar la facilidad de uso. ^[24]

RFC  8259 describe ciertos aspectos de la sintaxis JSON que, si bien son legales según las especificaciones, pueden causar problemas de interoperabilidad.

• Algunas implementaciones de JSON solo aceptan textos JSON que representan un objeto o una matriz. Para lograr la interoperabilidad, las aplicaciones que intercambian JSON deben transmitir mensajes que sean objetos o matrices.
• Las especificaciones permiten objetos JSON que contienen varios miembros con el mismo nombre. El comportamiento de las implementaciones que procesan objetos con nombres duplicados es impredecible. Para lograr la interoperabilidad, las aplicaciones deben evitar los nombres duplicados al transmitir objetos JSON.
• Las especificaciones establecen específicamente que el orden de los miembros en los objetos JSON no es significativo. Para lograr la interoperabilidad, las aplicaciones deben evitar asignar significado al orden de los miembros, incluso si el software de análisis hace que ese orden sea visible.
• Si bien las especificaciones no imponen límites a la magnitud o precisión de los literales numéricos JSON, la implementación de JavaScript ampliamente utilizada los almacena como cantidades "binary64" IEEE754. Para lograr la interoperabilidad, las aplicaciones deben evitar transmitir números que no se puedan representar de esta manera, por ejemplo, 1E400 o 3.141592653589793238462643383279.
• Si bien las especificaciones no restringen la codificación de caracteres Unicode en un texto JSON, la gran mayoría de las implementaciones suponen la codificación UTF-8 ; para la interoperabilidad, las aplicaciones siempre y solo deben codificar los mensajes JSON en UTF-8.
• Las especificaciones no prohíben la transmisión de secuencias de bytes que representen incorrectamente caracteres Unicode. Para lograr la interoperabilidad, las aplicaciones deben transmitir mensajes que no contengan dichas secuencias de bytes.
• La especificación no limita la forma en que las aplicaciones comparan cadenas Unicode. Para lograr la interoperabilidad, las aplicaciones siempre deben realizar dichas comparaciones unidad de código por unidad de código.

En 2015, el IETF publicó el RFC  7493, que describe el "Formato de mensaje I-JSON", un perfil restringido de JSON que restringe la sintaxis y el procesamiento de JSON para evitar, tanto como sea posible, estos problemas de interoperabilidad.

Si bien JSON proporciona un marco sintáctico para el intercambio de datos, el intercambio de datos inequívoco también requiere un acuerdo entre el productor y el consumidor sobre la semántica del uso específico de la sintaxis JSON. ^[25] Un ejemplo de dónde es necesario dicho acuerdo es la serialización de tipos de datos que no son parte del estándar JSON, por ejemplo, fechas y expresiones regulares .

El tipo MIME oficial para texto JSON es application/json, ^[26] y la mayoría de las implementaciones modernas lo han adoptado. Los tipos MIME heredados incluyen text/json, text/x-json, y text/javascript. ^[27]

JSON Schema especifica un formato basado en JSON para definir la estructura de los datos JSON para validación, documentación y control de interacción. Proporciona un contrato para los datos JSON requeridos por una aplicación determinada y cómo se pueden modificar esos datos. ^[28] JSON Schema se basa en los conceptos de XML Schema (XSD), pero está basado en JSON. Al igual que en XSD, se pueden utilizar las mismas herramientas de serialización/deserialización tanto para el esquema como para los datos, y es autodescriptivo. Se especifica en un borrador de Internet en el IETF, y la última versión a partir de 2024 es "Draft 2020-12". ^[29] Hay varios validadores disponibles para diferentes lenguajes de programación, ^[30] cada uno con distintos niveles de conformidad. La extensión de nombre de archivo estándar es .json. ^[31]

El estándar JSON no admite referencias a objetos , pero existe un borrador de estándar IETF para referencias a objetos basadas en JSON. ^[32]

JSON-RPC es un protocolo de llamada a procedimiento remoto (RPC) basado en JSON, que reemplaza a XML-RPC o SOAP . Es un protocolo simple que define solo unos pocos tipos de datos y comandos. JSON-RPC permite que un sistema envíe notificaciones (información al servidor que no requiere una respuesta) y múltiples llamadas al servidor que pueden responderse sin orden.

El JavaScript asincrónico y JSON (o AJAJ) se refieren a la misma metodología de páginas web dinámicas que Ajax , pero en lugar de XML , JSON es el formato de datos. AJAJ es una técnica de desarrollo web que proporciona la capacidad de una página web para solicitar nuevos datos después de que se hayan cargado en el navegador web . Por lo general, muestra nuevos datos del servidor en respuesta a las acciones del usuario en esa página web. Por ejemplo, lo que el usuario escribe en un cuadro de búsqueda , el código del lado del cliente lo envía al servidor, que responde inmediatamente con una lista desplegable de elementos de la base de datos que coinciden .

JSON ha sido utilizado ad hoc como lenguaje de configuración . Sin embargo, no admite comentarios . En 2012, Douglas Crockford, el creador de JSON, dijo lo siguiente sobre los comentarios en JSON cuando se utiliza como lenguaje de configuración: "Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así. Supongamos que está utilizando JSON para guardar archivos de configuración que le gustaría anotar. Siga adelante e inserte todos los comentarios que desee. Luego, páselos por JSMin ^[33] antes de entregárselos a su analizador JSON". ^[21]

MongoDB utiliza datos similares a JSON para su base de datos orientada a documentos .

Algunas bases de datos relacionales, como PostgreSQL y MySQL, han agregado compatibilidad con tipos de datos JSON nativos. Esto permite a los desarrolladores almacenar datos JSON directamente en una base de datos relacional sin tener que convertirlos a otro formato de datos.

El hecho de que JSON sea un subconjunto de JavaScript puede llevar a la idea errónea de que es seguro pasar textos JSON a la eval()función JavaScript. Esto no es seguro, debido a que ciertos textos JSON válidos, específicamente aquellos que contienen U+2028 LINE SEPARATOR o U+2029 PARAGRAPH SEPARATOR , no eran código JavaScript válido hasta que se actualizaron las especificaciones de JavaScript en 2019, por lo que es posible que los motores más antiguos no lo admitan. ^[34] Para evitar los numerosos problemas causados ​​por la ejecución de código arbitrario desde Internet, se agregó por primera vez una nueva función, , a la quinta edición de ECMAScript, ^{[35] que a partir de 2017 es compatible con todos los navegadores principales. Para los navegadores no compatibles,} Douglas Crockford proporciona una biblioteca JavaScript compatible con API . ^[36] Además, la propuesta TC39 "Subsume JSON" convirtió a ECMAScript en un superconjunto JSON estricto a partir de la revisión de 2019 del lenguaje. ^{[17] [18]} Varias implementaciones de analizadores JSON han sufrido ataques de denegación de servicio y vulnerabilidades de asignación masiva . ^{[37] [38]} JSON.parse()

JSON se promociona como una alternativa de bajo consumo de recursos a XML, ya que ambos formatos tienen un amplio soporte para la creación, lectura y decodificación en las situaciones del mundo real en las que se utilizan comúnmente. ^[39] Además de XML, los ejemplos podrían incluir CSV y superconjuntos de JSON. Google Protocol Buffers puede cumplir esta función, aunque no es un lenguaje de intercambio de datos. CBOR tiene un superconjunto de los tipos de datos JSON, pero no está basado en texto. Ion también es un superconjunto de JSON, con una gama más amplia de tipos primarios, anotaciones, comentarios y permite comas finales. ^[40]

XML se ha utilizado para describir datos estructurados y serializar objetos. Existen varios protocolos basados ​​en XML para representar el mismo tipo de estructuras de datos que JSON para el mismo tipo de propósitos de intercambio de datos. Los datos se pueden codificar en XML de varias maneras. La forma más expansiva que utiliza pares de etiquetas da como resultado una representación mucho más grande (en número de caracteres) que JSON, pero si los datos se almacenan en atributos y en forma de "etiqueta corta" donde la etiqueta de cierre se reemplaza por />, la representación suele tener aproximadamente el mismo tamaño que JSON o solo un poco más grande. Sin embargo, un atributo XML solo puede tener un único valor y cada atributo puede aparecer como máximo una vez en cada elemento.

XML separa los "datos" de los "metadatos" (mediante el uso de elementos y atributos), mientras que JSON no tiene ese concepto.

Otra diferencia clave es el direccionamiento de los valores. JSON tiene objetos con una simple asignación de "clave" a "valor", mientras que en XML el direccionamiento se produce en "nodos", que reciben todos un identificador único a través del procesador XML. Además, el estándar XML define un atributo común xml:id, que puede ser utilizado por el usuario, para establecer un identificador de forma explícita.

Los nombres de etiquetas XML no pueden contener ninguno de los caracteres !"#$%&'()*+,/;<=>?@[\]^`{|}~, ni un carácter de espacio, y no pueden comenzar con -, .o un dígito numérico, mientras que las claves JSON sí pueden (incluso si las comillas y la barra invertida deben escaparse). ^[41]

Los valores XML son cadenas de caracteres sin seguridad de tipos incorporada . XML tiene el concepto de esquema , que permite tipificación estricta, tipos definidos por el usuario, etiquetas predefinidas y estructura formal, lo que permite la validación formal de un flujo XML. JSON tiene varios tipos incorporados y tiene un concepto de esquema similar en JSON Schema.

XML admite comentarios, mientras que JSON no. ^{[42] [21]}

Se ha considerado útil la compatibilidad con comentarios y otras funciones, lo que ha llevado a la creación de varios superconjuntos JSON no estándar. Entre ellos se encuentran HJSON, ^[43] HOCON y JSON5 (que a pesar de su nombre, no es la quinta versión de JSON). ^{[44] [45]}

La versión 1.2 de YAML es un superconjunto de JSON; las versiones anteriores no eran estrictamente compatibles. Por ejemplo, escapar una barra /con una barra invertida \es válido en JSON, pero no lo era en YAML. ^[46] YAML admite comentarios, mientras que JSON no. ^{[46] [44] [21]}

CSON (" CoffeeScript Object Notation") utiliza sangría significativa , claves sin comillas y asume una declaración de objeto externa. Se utilizó para configurar el editor de texto Atom de GitHub . ^{[47] [48] [49]}

También existe un proyecto no relacionado llamado CSON ("Cursive Script Object Notation") que es sintácticamente más similar a JSON. ^[50]

HOCON ("Human-Optimized Config Object Notation") es un formato para datos legibles por humanos y un superconjunto de JSON. ^[51] Los usos de HOCON son:

• Se utiliza principalmente junto con el marco Play , ^[52] y está desarrollado por Lightbend .
• También se admite como formato de configuración para proyectos .NET a través de Akka.NET ^{[53] [54]} y Puppet . ^[55]
• TIBCO Streaming: ^[56] HOCON es el formato de archivo de configuración principal para la familia de productos TIBCO Streaming ^[57] (StreamBase, LiveView y Artifact Management Server) a partir de TIBCO Streaming Release 10. ^[58]
• También es el formato de archivo de configuración principal para varios subsistemas de Exabeam Advanced Analytics. ^[59]
• Jitsi lo utiliza como el "nuevo" sistema de configuración y los archivos .properties como respaldo ^{[60] [61]}

JSON5 ("JSON5 Data Interchange Format") es una extensión de la sintaxis JSON que, al igual que JSON, también es una sintaxis válida para JavaScript. La especificación se inició en 2012 y finalizó en 2018 con la versión 1.0.0. ^[62] Las principales diferencias con la sintaxis JSON son:

• Comas finales opcionales
• Claves de objeto sin comillas
• Cadenas entre comillas simples y de varias líneas
• Formatos de números adicionales
• Comentarios

La sintaxis JSON5 es compatible con algunos programas como una extensión de la sintaxis JSON, por ejemplo en SQLite . ^[63]

JSONC (JSON con comentarios) es un subconjunto de JSON5 utilizado en Visual Studio Code de Microsoft : ^[64]

• Admite comentarios de una sola línea ( //) y comentarios de bloque ( /* */)
• Acepta comas finales, pero no se recomiendan y el editor mostrará una advertencia.

Se han creado varios formatos de serialización a partir de la especificación JSON. Algunos ejemplos incluyen:

• GeoJSON , un formato diseñado para representar características geográficas simples ^{[65] [66]}

• JSON-LD , un método de codificación de datos vinculados utilizando JSON ^{[67] [68]}
• JSON-RPC , un protocolo de llamada a procedimiento remoto codificado en JSON ^[69]
• JsonML , un lenguaje de marcado ligero utilizado para mapear entre XML y JSON ^{[70] [71]}
• Sonrisa (formato de intercambio de datos) ^{[72] [73]}
• UBJSON , un formato binario de intercambio de datos informáticos que imita a JSON, pero que requiere menos bytes de datos ^{[74] [75]}

• BSON
• Comparación de formatos de serialización de datos
• Amazon Ion  : un superconjunto de JSON (aunque limitado a UTF-8 , como JSON para intercambio, a diferencia de JSON general)
• Jackson (API)
• jaql : un lenguaje de consulta y procesamiento de datos funcional más comúnmente utilizado para el procesamiento de consultas JSON
• jq – un "lenguaje de consulta JSON" y un lenguaje de programación de alto nivel
• JSONiq : un lenguaje de consulta y procesamiento orientado a JSON basado en XQuery
• Transmisión JSON
• Expresión S

• Sitio web oficial