Servicios Web: SOAP, REST y Estándares de Interoperabilidad

1. ¿Qué es un Servicio Web?

Un servicio web es un conjunto de métodos y estándares que permiten la interoperabilidad entre aplicaciones distintas, independientemente de la plataforma, el lenguaje de programación o el sistema operativo en que estén desarrolladas.

La interoperabilidad es la característica clave: un servicio web actúa como una interfaz estandarizada que expone funcionalidades de una aplicación para que otras aplicaciones puedan consumirlas a través de la red, típicamente Internet.

Definición formal (W3C): Un servicio web es un sistema software diseñado para soportar la interacción interoperable máquina-a-máquina a través de una red.

Características esenciales de un servicio web

Interoperabilidad: funciona entre sistemas heterogéneos.
Basado en estándares abiertos: XML, HTTP, JSON, WSDL, SOAP...
Accesible a través de la red: generalmente mediante protocolo HTTP/HTTPS.
Independiente de plataforma y lenguaje: un cliente Java puede consumir un servicio escrito en Python, .NET, etc.
Autodescriptivo: puede describir sus propias capacidades mediante documentos estándar (WSDL, OpenAPI...).

2. Tipos de Servicios Web

Existen principalmente dos grandes familias de servicios web:

Característica	SOAP	REST
Tipo	Protocolo	Estilo arquitectónico
Formato de mensaje	XML	JSON, XML, otros
Protocolo de transporte	HTTP, SMTP, TCP...	HTTP
Descripción	WSDL	OpenAPI / Swagger
Estado	Sin estado (stateless)	Sin estado (stateless)
Estándar	W3C	No hay un estándar único
Seguridad	WS-Security	HTTPS + OAuth
Complejidad	Mayor	Menor
Uso típico	Integración empresarial, banca	APIs web, móviles, microservicios

3. SOAP (Simple Object Access Protocol)

¿Qué es SOAP?

SOAP es un protocolo de comunicación basado en XML para el intercambio de información estructurada en entornos distribuidos. Fue desarrollado originalmente por Microsoft y posteriormente estandarizado por el W3C.

Estructura de un mensaje SOAP

Un mensaje SOAP es un documento XML con la siguiente estructura:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <!-- Información de cabecera opcional: autenticación, transacciones... -->
  </soap:Header>
  <soap:Body>
    <!-- Contenido del mensaje: petición o respuesta -->
    <ObtenerCliente>
      <idCliente>12345</idCliente>
    </ObtenerCliente>
  </soap:Body>
</soap:Envelope>

Envelope (Sobre): elemento raíz obligatorio que envuelve todo el mensaje.
Header (Cabecera): elemento opcional para metadatos (autenticación, trazabilidad...).
Body (Cuerpo): contiene el mensaje real (petición o respuesta).
Fault: elemento dentro de Body para informar de errores.

WSDL (Web Services Description Language)

Los servicios SOAP se describen mediante WSDL, un documento XML que especifica:

Qué operaciones ofrece el servicio.
Qué parámetros acepta cada operación.
Qué tipo de datos devuelve.
Dónde está disponible el servicio (endpoint).

Ventajas de SOAP

Independiente del protocolo de transporte (no solo HTTP).
Soporte nativo para transacciones, seguridad avanzada (WS-Security) y fiabilidad.
Muy adecuado para entornos empresariales con requisitos estrictos de seguridad.
Tipado fuerte gracias al uso de XML Schema (XSD).

Desventajas de SOAP

Mensajes más pesados (verboso por el XML).
Mayor complejidad de implementación.
Rendimiento inferior en comparación con REST para operaciones sencillas.

4. REST (Representational State Transfer)

¿Qué es REST?

REST no es un protocolo, sino un estilo arquitectónico definido por Roy Fielding en su tesis doctoral (2000). Se basa en los principios del protocolo HTTP y propone un conjunto de restricciones para diseñar sistemas distribuidos escalables.

Principios REST (Restricciones arquitectónicas)

Cliente-Servidor: separación de responsabilidades entre interfaz de usuario y almacenamiento de datos.
Sin estado (Stateless): cada petición del cliente debe contener toda la información necesaria; el servidor no almacena estado de sesión entre peticiones.
Caché: las respuestas deben indicar si son cacheables para mejorar el rendimiento.
Interfaz uniforme: interfaz estandarizada entre componentes (recursos, representaciones, mensajes autodescriptivos, HATEOAS).
Sistema en capas: el cliente no necesita saber si está conectado directamente al servidor final.
Código bajo demanda (opcional): el servidor puede enviar código ejecutable al cliente.

Recursos y URIs

En REST, todo es un recurso identificado por una URI (Uniform Resource Identifier):

https://api.ejemplo.com/clientes          → colección de clientes
https://api.ejemplo.com/clientes/123      → cliente con id 123
https://api.ejemplo.com/clientes/123/pedidos  → pedidos del cliente 123

Métodos HTTP en REST

Método HTTP	Operación CRUD	Descripción
GET	Read	Obtener un recurso o colección
POST	Create	Crear un nuevo recurso
PUT	Update	Actualizar un recurso completo
PATCH	Update	Actualizar parcialmente un recurso
DELETE	Delete	Eliminar un recurso

Formatos de representación

REST puede usar múltiples formatos, siendo JSON el más habitual:

{
  "id": 123,
  "nombre": "María García",
  "email": "maria@ejemplo.com",
  "fechaAlta": "2024-01-15"
}

Códigos de estado HTTP en REST

Código	Significado
200 OK	Petición exitosa
201 Created	Recurso creado correctamente
204 No Content	Éxito sin contenido en respuesta
400 Bad Request	Petición mal formada
401 Unauthorized	Autenticación requerida
403 Forbidden	Sin permisos
404 Not Found	Recurso no encontrado
500 Internal Server Error	Error del servidor

API RESTful

Una API RESTful es aquella que sigue los principios REST. Se documenta habitualmente con OpenAPI/Swagger, que define:

Endpoints disponibles.
Parámetros y cuerpos de petición.
Respuestas posibles y sus formatos.

5. Otros Estilos y Tecnologías de Servicios Web

XML-RPC

Precursor de SOAP. Protocolo sencillo que usa XML para codificar las llamadas a procedimientos remotos y HTTP como transporte. Actualmente en desuso.

GraphQL

Desarrollado por Facebook (2015). Es un lenguaje de consulta para APIs que permite al cliente especificar exactamente qué datos necesita. A diferencia de REST (múltiples endpoints), GraphQL expone un único endpoint.

query {
  cliente(id: "123") {
    nombre
    email
    pedidos {
      fecha
      total
    }
  }
}

gRPC

Desarrollado por Google. Framework de llamada a procedimiento remoto (RPC) de alto rendimiento que usa Protocol Buffers como formato de serialización binario. Muy eficiente para comunicaciones entre microservicios.

WebSockets

Protocolo que establece una conexión bidireccional y persistente entre cliente y servidor, a diferencia de HTTP (que es petición-respuesta). Útil para aplicaciones en tiempo real (chats, dashboards en vivo...).

6. Estándares Clave relacionados con Servicios Web

Estándar	Descripción
HTTP/HTTPS	Protocolo de transporte base para la mayoría de servicios web
XML	Lenguaje de marcado usado en SOAP y WSDL
JSON	Formato ligero de intercambio de datos, predominante en REST
WSDL	Descripción formal de servicios SOAP
UDDI	Directorio para publicar y descubrir servicios web (obsoleto en la práctica)
WS-Security	Estándar de seguridad para servicios SOAP
OAuth 2.0	Protocolo de autorización ampliamente usado en APIs REST
OpenAPI/Swagger	Especificación para describir APIs REST
SSL/TLS	Seguridad en la capa de transporte (HTTPS)

7. SOAP vs REST: ¿Cuándo usar cada uno?

Usar SOAP cuando:

Se requiere seguridad avanzada a nivel de mensaje (WS-Security).
Se necesita soporte para transacciones distribuidas.
El entorno es corporativo/empresarial con contratos formales estrictos.
Se trabaja con protocolos distintos a HTTP (SMTP, TCP...).
Ejemplos: servicios bancarios, pasarelas de pago, integración entre ERPs.

Usar REST cuando:

Se construyen APIs públicas o móviles.
Se prioriza la simplicidad y el rendimiento.
Se trabaja con arquitecturas de microservicios.
Se necesita escalabilidad horizontal.
Ejemplos: APIs de redes sociales, aplicaciones web modernas, servicios en la nube.

8. Conceptos Adicionales Relevantes

Endpoint

Dirección URL específica donde un servicio web está disponible y puede recibir peticiones.

Payload

Datos útiles que se envían o reciben en una petición/respuesta, excluyendo cabeceras y metadatos.

Idempotencia

Una operación es idempotente si ejecutarla múltiples veces produce el mismo resultado que ejecutarla una sola vez. En REST: GET, PUT y DELETE son idempotentes; POST no lo es.

Serialización / Deserialización

Proceso de convertir objetos en memoria a un formato transmisible (XML, JSON...) y viceversa.

API (Application Programming Interface)

Interfaz que define cómo interactúan dos sistemas. Los servicios web son un tipo de API accesible a través de la red.

Microservicios

Arquitectura donde una aplicación se divide en servicios pequeños e independientes que se comunican entre sí mediante APIs (habitualmente REST o gRPC).

Resumen Visual

SERVICIOS WEB
├── SOAP
│   ├── Protocolo formal basado en XML
│   ├── Descripción: WSDL
│   ├── Seguridad: WS-Security
│   └── Uso: entornos empresariales, banca
│
├── REST
│   ├── Estilo arquitectónico sobre HTTP
│   ├── Recursos identificados por URIs
│   ├── Métodos: GET, POST, PUT, DELETE...
│   ├── Formato: JSON (principalmente)
│   └── Uso: APIs web, móviles, microservicios
│
├── GraphQL
│   ├── Lenguaje de consulta para APIs
│   └── Un único endpoint flexible
│
└── gRPC
    ├── RPC de alto rendimiento (Google)
    └── Protocol Buffers (formato binario)

Documento de estudio para oposiciones — Tecnologías de la Información y Comunicación