Porqué estructurar una API sin JSON
A veces no tienes otro remedio, pero es importamnte que sepas que pueden hacerse API Sin JSON
- A veces no tienes otro remedio. Pero más importante que la necesidad es saber que puede hacerse, y que en muchos casos es la mejor decisión. Una API sin JSON no es un parche : es una arquitectura válida con décadas de historia detrás.
Allá por 1995 me tocó enfrentarme a las primeras APIs mal hechas. Eran en realidad cURL de un dominio de internet a otro. Para 2009 el estándar se llamaba SOAP, y yo no lo usaba por ser sobre-ingeniería. Más o menos por esas fechas empecé a usar XML-RPC, que es lo ideal en muchos casos, y también probé algo llamado Protocol Buffer, que casi nadie sabe usar y dejó de ser estándar.
Si bien los XML son en muchos aspectos un estándar, así como su versión indexada, tienen limitaciones. jQuery y otras librerías empezaron a usar JSON en 2010 aproximadamente, y el 23 de marzo de 2023 me encontré con un problema típico: Gemini trató de resolver ocho parámetros con un JSON y luego no lo pudo leer. Eso también les pasa a los desarrolladores humanos.
Desde hace muchos años hay interfaces importantes o APIs, ejemplo las de PayPal, Stripe, etc. En seguridad, las llamadas OAuth, y en términos de videojuegos, las APIs de Blizzard para World of Warcraft (que por desgracia no te dan el inventario), y otras más complejas como las del juego EVE Online.
Con el paso del tiempo las interfaces van evolucionando, y a veces para mal. Por ejemplo, EVE tenía un estándar API XML, luego se volvió CREST, ahora estamos en Swagger, y van a pasar a otra más, pero quién sabe cuándo. Esos cambios de API son un desastre.
En la vida real me ha tocado ver proyectos fallidos por validación de APIs. Ejemplo: una empresa de comunicaciones vía satélite recibía por XML-RPC algo de Volkswagen en dos formatos posibles de texto plano separado por || al inicio y al final, ||? solicitado por mí para indicar final de renglón. Se oye raro, pero es un estándar que he usado desde 1997.
El carácter | (pipe, chr(124)) se usa como separador y muchas veces lo ves en interfaces. Yo lo usaba probablemente desde antes de los codeblocks de Clipper 5.2.
Ejemplo:
Código
||PEDRO PEREZ PEREZ|MEXICO DF||11270||?
||LUCIA PEREZ HERNANDEZ|TOLUCA|1967-12-13|06500||?
¿Cuál es la diferencia contra JSON? JSON es un formato que incluye la “O” de Objeto. Como tal, no solamente puede evaluarse, sino que los parsers deben considerar que pueden faltar datos y hacen cientos de comprobaciones innecesarias.
La solución que yo usaba diez años antes de JSON era decir: siempre son cuatro campos. El espacio en blanco del primer renglón tenía que ver con la fecha de nacimiento. Se procesa más rápido.
En 2024, en una paraestatal, tuve que consumir datos de un microservicio que funcionaba cuando quería, en JSON. Pero el servidor que debía consumirlo y generar una imagen no tenía librerías. En un servidor propio de 5 USD, mandaba esa cadena encriptada (en mi ejemplo real eran 12 campos), la analizaba y regresaba la respuesta a otra página de mi sitio. Así se iban pasando de renglón en renglón de manera muy rápida. Si algo fallaba, sabía dónde resumir porque no tenía respuesta, y casi nunca fallaba.
Lo simple tiene valor de supervivencia.
En otro sistema me pasó tener que pegar texto generado en otro microservicio y recibido por un sistema en C# local. No había forma de pasarlo a otra cosa porque usaba librerías cifradas propietarias.
Qué hice:
- Pegaba líneas de código C generadas por un sistema PHP, algo así como:
Código
asyncwrite(“||numero incidencia 1||?||numero incidencia 2||?”);
asyncwrite(“||numero incidencia 3||?||numero incidencia 4||?”);
- Ese código lo ejecutaba con un F5.
- El F5 llamaba al microservicio Spring mal hecho de otro servidor que yo no controlaba, y me lo daba en modo consola modificado para salir en Firefox.
Resultado: Mi Firefox tenía al final:
Código
||Incidencia folio 1|APROBADA|dato 1|dato 2|dato 17||?
||Incidencia folio 2|APROBADA|dato 1|dato 2|dato 17||?
||Incidencia folio 800|APROBADA|dato 1|dato 2|dato 17||?
Literalmente, a veces procesaba en un solo paso 800 registros, y ese texto luego lo pegaba en mi servidor de 5 USD para que lo regresara a mi servidor original.
Era mucha vuelta, sí, pero necesaria por restricciones WAF y plataformas. Lo hacía unas cinco veces al día, pero podía tener un dashboard bastante actualizado a pesar de la red deficiente, restricciones absurdas de WAF y un microservicio hecho con SpringFaces y código propietario en Java que pasé a C# para correr en local.
Pasos técnicos:
- Traducir el código infumable de Java a un AES seguro en C.
- Crear un proyecto en C.
- Correrlo en local hasta que pude comunicarme con el webservice SpringFaces en el mismo idioma.
Se podía hacer más eficiente, sí, pero el sistema mexicano surrealista además tenía JSON mal formados y tuve que hacer mi propio parser. Dos días de cada tres las WAF bloqueaban el acceso, y no solo por JSON mal formados. La normalización y la coherencia me la daban los pipes en 1997, y 29 años después lo siguen haciendo.
Ahora vamos a hacer un sistema en Gemini, de astronomía, para consumo de APIs. Ese es el proyecto Kind Orbit. Voy a escribir estructura y reglas, pero no el sistema completo. Es un laboratorio, y por experiencia a veces es mejor no dar todos los detalles: no para evitar que te roben el trabajo, sino para que si experimentas encuentres cómo hacerlo. Además, si pongo todo mi código puede quedar desactualizado por cambios como los de EVE Online o World of Warcraft.
- La normalización y la coherencia me la daban los pipes en 1997, y 29 años después lo siguen haciendo. No todo lo que es viejo es obsoleto. A veces lo simple no es una limitación técnica — es una decisión de diseño que sobrevive porque funciona cuando todo lo demás falla.
La conclusión muy importante es :
LO SIMPLE TIENE VALOR DE SUPERVIVENCIA.
