OpoSERGASLa diferencia que más se pregunta entre SOAP y REST es que SOAP es un protocolo de mensajería con un formato de mensaje fijo (el sobre XML), mientras que REST es un estilo de arquitectura, no un protocolo: se apoya en recursos identificados por URI y en los métodos del propio HTTP. Es contenido del tema 14 de la parte específica de técnico/a especialista de sistemas y tecnologías de la información (C1) (servicios web, XML y arquitecturas orientadas a servicios), y el examen suele jugar con ese matiz.
SOAP: un mensaje con estructura obligatoria
La especificación SOAP 1.2 del W3C define el mensaje como un Envelope (sobre) que contiene, por este orden, un Header opcional y un Body obligatorio. La cabecera sirve para información de procesamiento (seguridad, enrutado, correlación); el cuerpo lleva la carga útil dirigida al receptor final. Si algo falla, el error se comunica con un elemento Fault, que debe ser el único hijo del Body.
El contrato de un servicio SOAP suele describirse con WSDL (Web Services Description Language), también del W3C (la versión 2.0 es Recomendación desde 2007; la 1.1, muy extendida, es una Nota de 2001): indica qué operaciones ofrece el servicio, qué mensajes intercambia y dónde se invoca.
REST: restricciones de arquitectura, no un estándar
REST procede de la tesis doctoral de Roy Fielding, que lo define como un conjunto de restricciones aplicadas a la arquitectura: cliente-servidor, sin estado (cada petición lleva toda la información necesaria para entenderla), caché, interfaz uniforme y sistema en capas. Una sexta, el código bajo demanda, es opcional. La interfaz uniforme se concreta en cuatro puntos: identificación de recursos, manipulación de recursos mediante representaciones, mensajes autodescriptivos e hipermedia como motor del estado de la aplicación.
En la práctica, un servicio REST sobre HTTP usa los métodos de HTTP con su significado. El RFC 9110 fija dos propiedades que conviene saber:
- Seguros (solo lectura, no piden cambiar el estado del servidor): GET, HEAD, OPTIONS y TRACE.
- Idempotentes (repetir la petición produce el mismo efecto que hacerla una vez): PUT, DELETE y todos los seguros. POST no es idempotente.
Comparativa para memorizar
| Aspecto | SOAP 1.2 | REST |
|---|---|---|
| Naturaleza | Protocolo de mensajería | Estilo de arquitectura |
| Formato del mensaje | Envelope con Header opcional y Body | Representación del recurso (no hay sobre obligatorio) |
| Contrato | WSDL (habitual, no obligatorio) | No exige un contrato formal |
| Qué se identifica | La operación que se invoca | El recurso, mediante una URI |
| Errores | Elemento Fault en el Body | Los propios códigos de estado HTTP |
| Estado | Depende del diseño del servicio | Sin estado en el servidor, por restricción |
Ejemplo práctico (ilustrativo)
Imagina que un hospital expone un servicio de citas. En un diseño REST, la cita 42 sería el recurso /citas/42: un GET la consulta, un PUT la reemplaza y un DELETE la anula. Si la red se corta justo después de enviar un DELETE y el cliente no recibe respuesta, puede repetirlo sin miedo, porque es idempotente. Un POST a /citas para crear una cita nueva no tiene esa garantía: repetirlo a ciegas podría crear dos citas. Con SOAP, en cambio, el cliente enviaría un sobre XML con la operación (por ejemplo, CrearCita) en el Body y recibiría otro sobre, o un Fault si algo falla.
Truco para recordarlo
Regla mnemotécnica propia, no oficial: SOAP = Sobre (Envelope, Header, Body) y REST = Recursos (URI + métodos HTTP). Para la idempotencia: «PUT y DELETE se pueden repetir; POST, no».
Practica con dos preguntas tipo test
1. Según el RFC 9110, ¿cuál de estos métodos HTTP NO es idempotente?
- PUT
- DELETE
- POST
- GET
Solución: C. POST no está entre los métodos definidos como idempotentes. PUT y DELETE sí lo son, y GET, al ser un método seguro, también.
2. En un mensaje SOAP 1.2, ¿qué elementos componen el Envelope?
- Un Header obligatorio y un Body opcional.
- Un Header opcional y un Body obligatorio.
- Solo un Body, sin posibilidad de Header.
- Un Fault obligatorio y un Body opcional.
Solución: B. La especificación define un Header opcional seguido de un Body obligatorio. La A invierte la obligatoriedad, la C niega la existencia del Header y la D confunde el Fault, que solo aparece para comunicar un error dentro del Body.
Referencias
- W3C, SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), apartados 5.1 a 5.4: w3.org/TR/soap12-part1.
- W3C, Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, Recomendación de 26 de junio de 2007: w3.org/TR/wsdl20.
- R. Fielding, Architectural Styles and the Design of Network-based Software Architectures (2000), capítulo 5 (University of California, Irvine).
- RFC 9110, HTTP Semantics, apartados 9.2.1 y 9.2.2: rfc-editor.org/rfc/rfc9110.
- Programa de la parte específica de técnico/a especialista de sistemas y tecnologías de la información (C1), tema 14, según la numeración del DOG núm. 126, de 5 de julio de 2021, al que remite el anexo II del DOG núm. 141/2025.
Sigue practicando
Repasa los códigos de estado HTTP que devuelve una API REST y consulta el temario de Técnico de Sistemas TI en PDF.
Crea tu cuenta gratis y practica los temas de Técnico de Sistemas TI.