API REST vs SOAP para el TAI: qué debes dominar del Bloque III

Portátil mostrando código en un escritorio con estantería de libros, representando el desarrollo de APIs

Si tienes que quedarte con una idea: REST es el estilo arquitectónico ligero y flexible que domina hoy la web y las APIs públicas, mientras que SOAP es el protocolo más rígido y formal que todavía sobrevive en sistemas heredados y en algunos servicios de la administración que exigen alto nivel de formalidad y seguridad transaccional. Para el Bloque III del TAI necesitas conocer ambos, pero sobre todo entender por qué existe esa diferencia.

¿Qué es una API REST y por qué la usa tanto la administración?

REST (Representational State Transfer) no es un protocolo, sino un estilo arquitectónico basado en el protocolo HTTP que define cómo deben comportarse los servicios web. Una API REST utiliza los verbos HTTP (GET, POST, PUT, DELETE) para operar sobre recursos identificados por URLs, y suele intercambiar la información en formato JSON, aunque también admite XML. Es stateless: cada petición contiene toda la información necesaria para ser procesada, sin depender de peticiones anteriores.

La administración electrónica ha ido migrando hacia REST porque es más ligero, más fácil de documentar (con estándares como OpenAPI) y más sencillo de integrar con aplicaciones móviles y frontales modernos.

Pantalla de ordenador mostrando código de una API en desarrollo
Las APIs REST son el estándar de facto en los nuevos desarrollos del sector público.

¿Qué es SOAP y en qué se diferencia de REST?

SOAP (Simple Object Access Protocol) es un protocolo de intercambio de mensajes basado en XML, con una estructura muy formal (sobre, cabecera y cuerpo) y reglas estrictas definidas en documentos WSDL (Web Services Description Language). A diferencia de REST, SOAP puede funcionar sobre distintos protocolos de transporte (no solo HTTP) e incluye mecanismos propios y muy robustos de seguridad y transacciones a través del estándar WS-Security.

Esa robustez tiene un coste: SOAP es más pesado, más lento de procesar y bastante más complejo de implementar que REST. Por eso sigue vivo sobre todo en sistemas bancarios, administrativos o de facturación electrónica donde ya estaba implantado y donde la garantía transaccional es crítica.

REST vs SOAP: tabla comparativa para el examen

Característica REST SOAP
Tipo Estilo arquitectónico Protocolo
Formato de datos JSON (habitualmente), XML XML exclusivamente
Transporte HTTP/HTTPS HTTP, SMTP, otros
Descripción del servicio OpenAPI/Swagger WSDL
Seguridad HTTPS, OAuth, tokens WS-Security (integrada)
BLOQUE III TAI
Desarrollo de Sistemas

Modelado de datos, lenguajes de programación, bases de datos, metodologías ágiles y servicios web explicados para el examen.

¿Cuál cae más en el examen TAI, REST o SOAP?

En las últimas convocatorias, las preguntas sobre servicios web tienden a centrarse en identificar correctamente las características de cada uno (sobre todo el formato de datos y el tipo de descripción del servicio) más que en detalles de implementación. Es habitual una pregunta del tipo "¿cuál de las siguientes afirmaciones sobre REST es correcta?" con distractores que mezclan características de SOAP. Dominar la tabla anterior te cubre la inmensa mayoría de esas preguntas.

Manos tecleando en un ordenador mientras se repasa la diferencia entre REST y SOAP
La clave está en no confundir las características de cada estilo bajo presión de tiempo.

Preguntas frecuentes

¿Se puede usar JSON con SOAP?

No de forma estándar. SOAP exige que los mensajes vayan en formato XML según su especificación; si un servicio usa JSON, ya no está siguiendo el protocolo SOAP.

¿REST es siempre mejor que SOAP?

No necesariamente. REST es más ligero y sencillo, pero SOAP ofrece garantías transaccionales y de seguridad más estrictas que siguen siendo necesarias en ciertos entornos, como algunos sistemas bancarios o de facturación electrónica del sector público.

¿Qué es un endpoint en una API REST?

Es la URL concreta a la que se dirige una petición para acceder a un recurso determinado, por ejemplo /api/ciudadanos/123 para consultar los datos del ciudadano con identificador 123.

¿Qué relación tiene esto con el resto del Bloque III?

Los servicios web conectan directamente con otros epígrafes del Bloque III como el modelado de datos y las metodologías de desarrollo, porque una API bien diseñada necesita un modelo de datos claro detrás.

¿Se te resiste el Bloque III?

Los apuntes cubren desarrollo de sistemas de principio a fin, incluidos los servicios web que más caen en el examen.

Consigue el Bloque III por 19,99 € →