¿Por qué las API de AWS devuelven XML? - La historia de la evolución desde Query API hasta REST JSON
Explicamos las razones históricas por las que las API de S3 y EC2 devuelven respuestas XML, las diferencias entre Query API y REST API, la evolución de la autenticación de Signature V2 a V4, y la complejidad que los SDK ocultan.
El diseño de API en 2006 - Una era donde XML era lo natural
Cuando S3 y EC2 se lanzaron en 2006, XML era el formato de datos estándar en el mundo de las Web API. SOAP (Simple Object Access Protocol) era la corriente principal de los servicios web empresariales, y la definición estricta de tipos mediante XML Schema y la descripción de servicios mediante WSDL (Web Services Description Language) se consideraban el diseño de API "correcto". JSON había sido propuesto por Douglas Crockford en 2001, pero en 2006 aún no estaba ampliamente difundido y se evaluaba como "ligero pero carente de seguridad de tipos". AWS eligió un enfoque intermedio: no adoptó SOAP completo, sino un formato más simple llamado Query API. El Query API envía parámetros como query strings en solicitudes HTTP GET/POST y recibe respuestas en XML. Este diseño era más simple que SOAP pero mantenía la expresividad de XML. La API de EC2 (ec2.amazonaws.com/?Action=DescribeInstances&Version=2006-10-01) sigue funcionando con este formato hasta hoy.
La maldición de la compatibilidad retroactiva - ¿Por qué no se puede eliminar XML?
Uno de los principios de diseño más importantes de AWS es "no deprecar APIs una vez publicadas". La Query API de EC2 ha estado funcionando durante casi 20 años desde 2006, y el formato de respuesta XML no ha cambiado. Dado que las aplicaciones de millones de clientes dependen de esta API, cambiar el formato de respuesta a JSON sería un cambio disruptivo a gran escala. AWS resuelve este problema adoptando JSON en los nuevos servicios mientras mantiene las API de los servicios antiguos tal como están. Los servicios lanzados después de 2012 (DynamoDB, Lambda, API Gateway, etc.) utilizan REST API con JSON desde el principio. Esto significa que dentro de AWS coexisten dos generaciones de estilos de API. Los servicios antiguos (EC2, S3, SQS, SNS, etc.) usan Query API + XML, mientras que los servicios nuevos (Lambda, DynamoDB, ECS, etc.) usan REST API + JSON. Los SDK absorben esta diferencia internamente, por lo que los desarrolladores no necesitan ser conscientes de ella.
Signature V4 - El mecanismo que firma todas las solicitudes
Otra característica de las API de AWS es que todas las solicitudes requieren una firma criptográfica. El estándar actual, Signature Version 4 (SigV4), concatena el método HTTP, la URL, los headers y el body de la solicitud, los hashea, y genera una firma HMAC-SHA256 con la clave de acceso secreta. Esta firma se incluye en el header Authorization y se verifica del lado de AWS. El proceso de firma de SigV4 consta de 4 pasos. Primero, la creación de la Canonical Request: se normaliza el método HTTP, URI, query string y headers en un formato determinado y se calcula su hash SHA-256. Segundo, la creación del String to Sign: se combina el algoritmo, la fecha, el scope de credenciales y el hash de la canonical request. Tercero, la derivación de la Signing Key: se aplica HMAC-SHA256 en cadena a la fecha, región, servicio y "aws4_request" usando la clave de acceso secreta. Cuarto, el cálculo de la firma: se firma el String to Sign con la Signing Key. Este proceso complejo se ejecuta para cada solicitud de API. Implementarlo manualmente es propenso a errores, lo cual es una de las razones por las que el uso del SDK es prácticamente obligatorio.
La complejidad que los SDK ocultan
Los SDK de AWS son una enorme capa de abstracción que oculta la complejidad de las API a los desarrolladores. Lo que el SDK procesa internamente es muy diverso: firma de solicitudes (SigV4), serialización/deserialización de XML/JSON, lógica de reintentos (con backoff exponencial), manejo de errores (distinción entre errores temporales y permanentes), paginación (obtención automática de grandes cantidades de resultados en múltiples solicitudes), resolución de endpoints regionales, y actualización automática de credenciales temporales (AssumeRole de roles IAM). El SDK v3 (JavaScript) y boto3 (Python) implementan estos procesos como middleware o plugins, permitiendo a los desarrolladores personalizar el comportamiento según sea necesario. Sin embargo, la mayoría de los desarrolladores nunca necesitan tocar estas capas internas. La existencia del SDK significa que la complejidad de las API de AWS no se convierte directamente en complejidad para los desarrolladores. Pero también significa que cuando ocurren problemas (errores de firma, timeouts, throttling), comprender lo que el SDK está haciendo internamente se vuelve importante para la depuración.
La evolución de las API y la dirección futura
El diseño de API de AWS ha evolucionado significativamente en 20 años. Desde la Query API + XML inicial, pasando por REST + JSON, y recientemente hacia GraphQL (AppSync) y event-driven (EventBridge), los paradigmas de API se han diversificado. Lo que se mantiene consistente en el diseño de API de AWS es el principio de "no cambiar una API una vez publicada". La versión de API de EC2 2006-10-01 sigue funcionando hoy. Las nuevas funcionalidades se añaden como nuevas versiones de API, y las versiones antiguas no se deprecan. Este mantenimiento de la compatibilidad retroactiva es la base de la confiabilidad de AWS. Las empresas pueden construir sistemas con la confianza de que las API que usan hoy seguirán funcionando dentro de varios años. Para aprender sobre diseño de API y su evolución, los libros especializados (Amazon) son una referencia útil.