≡En resumen
- Un web service permite que dos programas intercambien datos por la red siguiendo un contrato conocido por ambos.
- En sentido estricto (W3C) es un servicio SOAP descrito con WSDL; en el uso diario el término abarca también las API REST y GraphQL.
- SOAP sigue vivo en banca, seguros y administración: el SII de la Agencia Tributaria y el validador europeo VIES usan servicios SOAP.
- Para proyectos nuevos se suele elegir REST con JSON por su sencillez; GraphQL cuando muchas pantallas consumen los mismos datos.
- Un web service expuesto a Internet necesita autenticación, cifrado TLS, límites de uso y versiones bien documentadas.
01 ¿Qué son los web services o servicios web?
El término se popularizó a finales de los noventa y principios de los 2000, cuando las empresas necesitaban conectar sistemas escritos en Java, .NET o COBOL a través de Internet. El W3C lo definió en 2004 como un sistema diseñado para la interacción interoperable de máquina a máquina en una red, con una interfaz descrita en un formato procesable por máquinas (WSDL) y mensajes SOAP transportados normalmente por HTTP.
Hoy, en la práctica, «servicio web» se usa como sinónimo amplio de API web: cualquier interfaz que otra aplicación consume por HTTP. Por eso conviene distinguir entre el sentido estricto (SOAP + WSDL) y el sentido amplio, que incluye REST, GraphQL y los webhooks.
Proveedor
El sistema que publica el servicio: expone una URL (endpoint) y define qué operaciones acepta y qué devuelve.
Consumidor
La aplicación que llama al servicio: una web, una app móvil, un ERP o un script de automatización.
Contrato
La descripción del servicio: un WSDL en SOAP o una especificación OpenAPI o un esquema GraphQL en los estilos modernos.
Mensaje
Los datos que viajan: un sobre XML en SOAP o un documento JSON en REST y GraphQL.
02 Cómo funciona un servicio web paso a paso
-
1
El cliente prepara la petición
Construye el mensaje con los datos de entrada (por ejemplo, un NIF) en el formato que exige el contrato.
-
2
La envía por HTTP o HTTPS
La petición viaja al endpoint del proveedor, casi siempre cifrada con TLS y con una credencial: token, clave de API o certificado.
-
3
El servidor valida y procesa
Comprueba la autenticación y el formato, ejecuta la operación y consulta su base de datos o sus propios servicios.
-
4
Devuelve la respuesta
Responde con los datos pedidos o con un error estructurado y un código de estado HTTP que el cliente sabe interpretar.
-
5
El cliente usa el resultado
Muestra el dato al usuario, lo guarda o lanza el siguiente paso de un proceso automatizado.
03 Tipos de web services: SOAP vs REST vs GraphQL
No todos los servicios web se construyen igual. SOAP es un protocolo con reglas estrictas; REST es un estilo de arquitectura que aprovecha HTTP tal cual, descrito por Roy Fielding en su tesis de 2000; GraphQL es un lenguaje de consultas que Facebook publicó como código abierto en 2015 y cuya especificación mantiene hoy la GraphQL Foundation. Si quieres el detalle de verbos, códigos de estado y buenas prácticas del estilo más usado, lo tienes en la ficha de API REST.
| Aspecto | SOAP | REST | GraphQL |
|---|---|---|---|
| Naturaleza | Protocolo (W3C) | Estilo de arquitectura | Lenguaje de consultas con especificación propia |
| Formato | XML obligatorio (sobre SOAP) | Normalmente JSON | JSON |
| Contrato | WSDL | OpenAPI (opcional pero habitual) | Esquema tipado (SDL) |
| Endpoints | Uno por servicio, con operaciones | Una URL por recurso | Normalmente uno solo |
| Errores | SOAP Fault dentro del XML | Códigos de estado HTTP | Campo errors en la respuesta |
| Dónde se usa | Banca, seguros, administración, sistemas heredados | Webs, apps móviles, SaaS | Apps con muchas pantallas y datos relacionados |
04 WSDL, XML y JSON: el contrato y el formato de los datos
El WSDL (Web Services Description Language) es un documento XML que describe un servicio SOAP: qué operaciones ofrece, qué parámetros recibe cada una, qué devuelve y en qué URL escucha. Con él, herramientas como SoapUI o los generadores de Java y .NET crean automáticamente el código cliente. La versión 2.0 es Recomendación del W3C desde junio de 2007, aunque en la práctica sigue siendo muy común WSDL 1.1.
En los servicios modernos el papel del WSDL lo cumple una especificación OpenAPI, y el formato de los mensajes suele ser JSON, más ligero y fácil de leer que XML.
La Comisión Europea publica el WSDL de su servicio checkVatService. Un programa de facturación envía en un sobre SOAP el código de país (ES) y el número de IVA del cliente; el servicio responde si el número es válido y, cuando el Estado lo permite, el nombre y la dirección de la empresa. Así se comprueba automáticamente a un cliente intracomunitario antes de emitir una factura sin IVA.
| Criterio | XML | JSON |
|---|---|---|
| Legibilidad | Verboso, con etiquetas de apertura y cierre | Compacto: pares clave-valor y listas |
| Validación | Esquemas XSD muy estrictos | JSON Schema, menos extendido |
| Firmas y cifrado en el mensaje | Estándares maduros (XML Signature, WS-Security) | JWS y JWE, más recientes |
| Uso típico | SOAP, administración, sectores regulados | REST, GraphQL, apps y SaaS |
05 Ejemplos de web services en empresas y administraciones
Pagos online
La tienda envía el importe a la pasarela de pago y recibe la autorización; después un webhook confirma el cobro.
Logística
Tarifas, etiquetas y seguimiento de envíos se consultan en el servicio web de la empresa de transporte.
Fiscalidad
El Suministro Inmediato de Información (SII) de la Agencia Tributaria recibe facturas mediante servicios web SOAP firmados con certificado.
ERP y CRM
Pedidos, clientes y stock se sincronizan entre la web y el sistema de gestión sin teclear nada dos veces.
Mapas y datos
Geocodificación, tiempo, cotizaciones o traducción automática se integran como servicios de terceros.
Inteligencia artificial
Los modelos de lenguaje se consumen como servicios web: la app envía un texto y recibe la respuesta generada.
Muchas de estas integraciones ya no requieren programar desde cero: herramientas de automatización llaman a servicios web con conectores visuales. Si te interesa ese enfoque, en la guía qué es n8n y cómo automatiza procesos tienes ejemplos. Cuando la lógica es propia del negocio, lo habitual es construir el servicio dentro de un proyecto de desarrollo de aplicaciones web a medida.
06 Cómo crear o consumir un servicio web con seguridad
- ✓Publica el contrato (WSDL u OpenAPI) y mantenlo sincronizado con el código.
- ✓Usa siempre HTTPS con TLS y autenticación: OAuth 2.0, claves de API o certificados de cliente.
- ✓Valida cada entrada en el servidor, aunque el cliente ya lo haga.
- ✓Limita el número de peticiones por cliente (rate limiting) para evitar abusos.
- ✓Versiona el servicio (v1, v2) para no romper integraciones existentes.
- ✓Devuelve errores claros y registra cada llamada para poder auditarla.
- ✓En el cliente, gestiona tiempos de espera y reintentos: el servicio remoto puede fallar.
Cuando además hay una app móvil que consume los mismos servicios, conviene diseñarlos pensando en ambos clientes desde el principio; es lo que hacemos en proyectos de desarrollo de apps a medida.
07 Web service vs API: ¿es lo mismo?
Todo web service es una API, pero no toda API es un web service. Una API es cualquier interfaz entre programas: la de un sistema operativo, la de una librería o la de un navegador. Un web service es, en concreto, una API accesible a través de la red con protocolos web. En el lenguaje del día a día muchos equipos usan «servicio web» para lo SOAP y «API» para lo REST, aunque técnicamente ambos son servicios web.
| API | Web service | |
|---|---|---|
| Alcance | Cualquier interfaz entre componentes de software | Interfaz expuesta a través de una red |
| Necesita red | No siempre (puede ser local) | Sí |
| Protocolos | Cualquiera | HTTP/HTTPS y estándares web |
| Ejemplo | La API de geolocalización del navegador | El servicio VIES de validación de IVA |
Preguntas frecuentes sobre Web Services
Es un programa accesible por Internet al que otras aplicaciones hacen preguntas o encargan tareas y del que reciben respuestas en un formato estándar como XML o JSON.
Sirven para conectar sistemas distintos: una tienda con su pasarela de pago, un ERP con la web, una app con su servidor o una empresa con la Agencia Tributaria.
SOAP es un protocolo con mensajes XML y un contrato WSDL obligatorio; REST es un estilo de arquitectura que usa las URL y los verbos de HTTP, normalmente con JSON, y es más ligero.
Es el documento XML que describe un servicio web SOAP: sus operaciones, parámetros, respuestas y dirección. Las herramientas lo leen para generar el código cliente automáticamente.
No exactamente. Un web service es un tipo de API que funciona a través de la red con protocolos web; el término API es más amplio e incluye interfaces locales.
Sí. Aunque los proyectos nuevos prefieren REST, SOAP sigue presente en banca, seguros y administraciones, como el SII de la Agencia Tributaria o el servicio VIES de la UE.
Validar un NIF-IVA en VIES, cobrar con una pasarela de pago, calcular un envío con una empresa de transporte, enviar facturas al SII o consultar un modelo de IA por su API.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗