Probador de JSONPath

Qué es JSONPath

JSONPath es un lenguaje de consulta para JSON, igual que XPath lo es para XML. Una expresión como $.store.book[?@.price < 10].title se adentra en un documento y extrae las partes que quieres: todos los libros por debajo de diez y solo su título. Aparece en Kubernetes y kubectl, en configuraciones de CI, en tuberías de logs, en pasarelas de API y en muchísimas bibliotecas que necesitaban una forma de decir a qué parte de un payload se referían.

Durante casi toda su vida no tuvo especificación. Empezó como una entrada de blog en 2007, todo el mundo lo implementó a partir de esa descripción y las implementaciones discrepaban en silencio: la misma consulta podía devolver cosas distintas, en otro orden, según el lenguaje en el que la ejecutaras. No había ningún documento al que apelar cuando dos de ellas diferían.

El RFC 9535 lo cambió en febrero de 2024. Este probador ejecuta una implementación real de ese estándar: pega una consulta y un documento y obtienes los nodos que coinciden, la ruta normalizada de cada uno y una afirmación sobre si el orden que estás viendo está garantizado.

Cómo se usa

1. Escribe una consulta. Parte de los ejemplos si quieres: uno filtra por precio, otro reúne todos los precios del documento y dos muestran qué pasa cuando el orden no está fijado. Los resultados se actualizan mientras escribes.
2. Pega tu JSON. Cualquier documento válido. Si no se puede analizar, la herramienta lo dice en vez de fingir que falló la consulta.
3. Lee las rutas y la nota sobre el orden. Cada resultado lleva su ruta normalizada, la única forma inequívoca de dirigirse a ese nodo. Debajo, la herramienta indica si cualquier implementación conforme devolvería estos nodos en este orden o si otra es libre de diferir.

Lo que el estándar zanja, y las dos cosas que no

La buena noticia es cuánto fija el RFC 9535. La expresión implementation-defined no aparece ni una vez. El orden del recorrido descendente, la semántica de los cortes con paso negativo, qué hace una comparación cuando un lado no selecciona nada: todo especificado, todo comprobable.

Hay exactamente dos sitios donde el orden del resultado queda abierto, y la especificación nombra los dos en vez de dejar que los descubras. El primero es seleccionar miembros de un objeto: los objetos JSON no tienen orden, así que un comodín sobre uno puede volver en cualquier sentido. Los arreglos no se ven afectados —su orden se conserva siempre—, que es justo la mitad que la gente suele dar por perdida.

El segundo es un segmento con más de un selector, como [0,0] o [*,*]. Eso produce cada nodo coincidente una vez por selector —duplicado de verdad, no deduplicado— y el entrelazado no está fijado. Este merece conocerse porque la especificación se toma la molestia de decir que las implementaciones que devuelven ese nodo una sola vez no son conformes. Si te has apoyado en que una biblioteca colapse los duplicados, ese comportamiento no es el estándar.

La regla que más implementaciones antiguas incumplen es la de tipos. Una comparación solo puede involucrar un literal, una consulta singular —una que como mucho seleccione un nodo— o una función que devuelva un valor. Así que $[?@.* == 1] es un error de sintaxis, no una comparación que en silencio no coincide con nada. Y una ruta que no selecciona nada produce un valor especial llamado Nothing, que solo es igual a sí mismo: dos rutas ausentes comparan iguales, mientras que una ruta ausente no es ni menor ni mayor que un número. De la propia derivación de los operadores en la especificación se sigue que dos rutas ausentes también comparan menor-o-igual.

Cómo se comprobó este motor, y qué no demuestra eso

El RFC 9535 incluye una suite oficial de conformidad, lo que convierte en un número lo bien que funciona una implementación. Son 703 pruebas y este motor las supera todas. Esa cifra se comprueba en la compilación, así que no puede pudrirse en silencio.

Un tercio de ese corpus —247 pruebas— son consultas que hay que rechazar. Ahí es donde falla un analizador permisivo, y es una parte considerable del trabajo: el estándar es estricto con los espacios en blanco, con dónde puede aparecer una consulta no singular y con qué escapes son legales dentro de un nombre entrecomillado. Aceptar una consulta malformada cuenta como fallo aunque no hubiera respuesta sensata posible.

Una puntuación perfecta no demuestra corrección, y esta compilación lo ilustra bien. La especificación define solo dos operadores de comparación y deriva los demás, de modo que a menor-o-igual que b significa a menor que b o a igual a b. Como dos Nothing comparan iguales, dos Nothing tienen que comparar también menor-o-igual. Una versión escrita a mano de ese operador devolvía false en su lugar, y la suite de conformidad puntuó 703 de 703 con el fallo presente, porque el corpus no cubre ese caso. Lo cazaron unas comprobaciones aparte derivadas del texto de la especificación y no de sus pruebas.

Los límites que conviene decir: la herramienta analiza tu documento con el propio analizador JSON del navegador, así que un número demasiado grande para un double ya viene redondeado antes de que la consulta lo vea; el estándar tiene bastante que decir sobre números interoperables y nada de ello puede rescatar un valor que se perdió al analizar. Las expresiones regulares dentro de match y search siguen el RFC 9485, que es un subconjunto pequeño sin grupos de captura, anticipación ni retrorreferencias; un patrón que las use no es una I-Regexp válida y la función está definida para devolver false en vez de dar error.

¿Por qué es gratis?

El motor se ejecuta en tu navegador. Analizar una consulta y recorrer un documento no cuesta nada en tu propia máquina, así que no hay servidor que pagar ni cuenta que crear.

Nada de lo que pegas se sube, se guarda ni se registra. El JSON que estás depurando suele ser un payload real de un sistema real, y la forma fiable de mantenerlo en privado es no recibirlo nunca.