Validar la respuesta JSON de una API antes de procesarla

Cuando su aplicación llama a una API y espera JSON, da por hecho que el cuerpo de la respuesta se podrá convertir en objetos y arreglos. Sin embargo, esa suposición falla más a menudo de lo que parece. Un servicio puede devolver una página de error en HTML en lugar de JSON, un proxy puede insertar contenido inesperado, o la respuesta puede llegar truncada por un tiempo de espera agotado. Si su código intenta interpretar ese cuerpo sin comprobarlo, se producirá una excepción en tiempo de ejecución justo en el punto de la conversión. Validar la respuesta por separado, antes de escribir o depurar la lógica que la consume, le permite aislar el problema: sabrá si el fallo está en el formato de los datos o en su propio código.

Que una respuesta sea JSON bien formado significa que respeta al pie de la letra las reglas del formato. Cada clave de cada objeto va entre comillas dobles, igual que todas las cadenas de texto. Los valores solo pueden ser cadenas, números, los literales true, false y null, objetos o arreglos. Los pares y los elementos se separan con comas, sin que aparezca ninguna coma sobrante tras el último. Las llaves y los corchetes deben abrirse y cerrarse de forma equilibrada. La especificación no admite comentarios ni comillas simples. La herramienta comprueba todas estas condiciones sobre el cuerpo que usted pega. Si una sola de ellas no se cumple, la respuesta no es JSON válido y ningún cliente estándar podrá deserializarla, por muy correcta que parezca a primera vista.

Las respuestas de API presentan fallos característicos que conviene reconocer. Uno muy común es que el servidor anteponga o añada texto que no forma parte del JSON, como una advertencia, un código de depuración o marcas de un framework. Otro caso frecuente son las respuestas envueltas, en las que el JSON real llega dentro de otra cadena escapada y requiere una segunda interpretación. También aparecen problemas de codificación, con caracteres especiales mal representados, o respuestas parciales cuando la conexión se corta antes de recibir el cierre final. Al pegar el cuerpo completo en la herramienta y validarlo, verá enseguida si el problema es de sintaxis o de contenido inesperado. El mensaje de error, con su línea y su posición, le indica dónde deja de ser válido el texto, que suele ser justo donde se coló el elemento ajeno.

Las respuestas de API a menudo contienen información delicada: identificadores de usuario, tokens, direcciones de correo o datos de negocio. Por eso importa que la validación ocurra en su navegador y no en un servidor remoto. Cuando pega el cuerpo en esta herramienta, el análisis se ejecuta en local, sobre la propia página, sin transmitir nada por la red. Su respuesta no se almacena, no se registra y no se comparte con terceros; permanece en su equipo del principio al fin. Esta característica es especialmente valiosa en entornos corporativos, donde subir datos de clientes a un servicio externo puede infringir políticas de seguridad o normativas de privacidad. Puede validar tantas respuestas como necesite, incluidas las de entornos de producción, con la tranquilidad de que su contenido nunca abandona el navegador.

Validar la respuesta antes de consumirla reproduce exactamente lo que hará su código al recibirla. En la mayoría de lenguajes, deserializar JSON equivale a lo que el método JSON.parse hace en JavaScript: convierte el texto en datos y falla si encuentra cualquier desviación de la especificación. Si la herramienta marca el cuerpo como válido, tiene la garantía de que su parser no fallará por motivos de formato y podrá centrarse en la lógica de negocio. Si lo marca como no válido, ha localizado el problema sin necesidad de ejecutar ni depurar su aplicación. Este flujo ahorra tiempo: en lugar de perseguir una excepción entre capas de código, comprueba el dato de entrada de forma aislada y decide si el arreglo corresponde al cliente, al servidor de la API o a la forma en que capturó la respuesta.