Arquitectura de sistemas cliente/servidor y multicapas: componentes y operación. Arquitecturas de servicios web y protocolos asociados.

Tema desarrollado para el ejercicio único del Cuerpo de Técnicos Auxiliares de Informática de la Administración del Estado. Es el tema 6 del bloque III «Desarrollo de sistemas», que en nuestra numeración interna es el tema 20 de 33.

Cuánto pesa y cómo pregunta. 78 preguntas oficiales de las nueve convocatorias tocan esta materia, y no están repartidas por igual: la mitad larga son de servicios web —REST, SOAP, WSDL, códigos de estado HTTP— y el resto se reparte entre la arquitectura en capas y la seguridad de la comunicación. El tribunal ha preguntado cuatro veces la misma idea con distintas palabras: que REST es un estilo de arquitectura sin estado y no un protocolo. Quien tenga eso claro se lleva media docena de puntos.

La otra mitad se juega en detalles que no se razonan, se reconocen: que el código de «creado» es el 201 y el de «demasiadas peticiones» el 429; que PUT es idempotente pero no seguro; que la última versión de SOAP es la 1.2; que las peticiones SOAP se firman con WS-Security; que REST no sirve para documentar servicios y RAML, WSDL y OpenAPI sí; y que los componentes de una arquitectura orientada a servicios son cuatro, con el registro como el que siempre falta en los distractores. Este apunte los lleva todos, cada uno con la razón por la que es así.

Índice

1. El modelo cliente/servidor
   • Qué problema resuelve y qué lo define
   • Los componentes: cliente, servidor, middleware y red
   • Cliente ligero, cliente pesado y el reparto de la carga
   • Cómo opera: petición-respuesta, estado y concurrencia
2. De una capa a n capas
   • El punto de partida: centralizado y monolítico
   • Dos capas
   • Tres capas
   • N capas o multinivel
   • Ventajas e inconvenientes, con la trampa del tribunal
   • Capa lógica y nivel físico no son lo mismo
3. El middleware
   • Las familias de middleware
   • Llamada a procedimiento remoto: RPC, RMI, CORBA y DCOM
   • Middleware orientado a mensajes
4. Escalabilidad, balanceo y disponibilidad
   • Escalar hacia arriba y escalar hacia los lados
   • El balanceador de carga y el problema de la sesión
   • Proxy, proxy inverso y caché
5. Qué es un servicio web
6. La arquitectura orientada a servicios (SOA)
   • Los cuatro componentes
   • El bus de servicios, orquestación y coreografía
   • SOA en la Administración: la PID y el protocolo SCSP
7. La pila SOAP y las especificaciones WS-*
   • SOAP: el sobre y sus partes
   • WSDL: el contrato
   • UDDI, WSIL y el registro
   • WS-Security y las demás WS-*
   • Del WSDL al código
8. REST
   • Qué es y qué no es
   • Las seis restricciones
   • Recursos, URI y representaciones
   • Los verbos: seguro e idempotente
   • Los códigos de estado
   • Madurez y HATEOAS
   • REST frente a SOAP
9. Documentar y probar servicios
10. Seguridad de los servicios web
    • Cómo se identifica quien llama
    • CORS y el origen cruzado
    • Limitación de peticiones
    • HTTPS, TLS y el puerto 80
    • El cortafuegos de aplicación web
11. Microservicios
    • Del monolito a los microservicios
    • Las piezas que aparecen siempre
    • Contenedores y orquestación
    • Cuándo NO conviene
12. Otros estilos y protocolos
13. El protocolo HTTP por dentro
    • La petición y la respuesta
    • Cabeceras que se preguntan
    • Cookies: HttpOnly, Secure y SameSite
    • HTTP/1.1, HTTP/2 y HTTP/3
14. Cuadros para memorizar
15. Lo que ya ha preguntado el tribunal

1. El modelo cliente/servidor

1.1. Qué problema resuelve y qué lo define

Antes del modelo cliente/servidor, la informática de gestión era centralizada: un ordenador grande hacía todo el trabajo y los usuarios se asomaban a él por terminales sin inteligencia, que solo pintaban caracteres y mandaban pulsaciones. Funcionaba, pero tenía dos defectos que acabaron con el modelo: todo el coste estaba en una máquina que había que sobredimensionar, y la interfaz era la que el equipo central supiera generar.

El modelo cliente/servidor parte de una idea distinta: repartir el trabajo entre dos programas que se comunican por una red, cada uno especializado en lo suyo. Sus rasgos definitorios, que son los que se preguntan:

• Asimetría de papeles. El cliente es quien inicia la conversación y pide; el servidor espera y responde. No es una relación entre iguales, y esa es justo la diferencia con el modelo entre pares, donde cada nodo es cliente y servidor a la vez.
• Servicio. El servidor ofrece una función concreta —datos, ficheros, impresión, correo, autenticación— y la ofrece a muchos clientes a la vez.
• Transparencia de ubicación. El cliente pide el servicio por su nombre; dónde esté físicamente el servidor no debería importarle. Es lo que permite mover el servidor sin tocar el cliente.
• Independencia de plataforma. Cliente y servidor pueden correr sobre sistemas operativos y máquinas distintas, porque lo que comparten es un protocolo, no un programa.
• Encapsulamiento del servicio. El cliente conoce qué pide y con qué formato, no cómo se resuelve. Cambiar el gestor de base de datos por dentro no debería afectarle.
• Escalabilidad en las dos direcciones y reparto de la carga entre las dos partes.

Una precisión que evita confusiones: cliente y servidor son papeles, no máquinas. Un servidor de aplicaciones es servidor frente al navegador y cliente frente a la base de datos, al mismo tiempo y en la misma petición. Cuando un enunciado dice «el servidor», hay que preguntarse siempre servidor de qué.

1.2. Los componentes: cliente, servidor, middleware y red

La descomposición clásica del modelo tiene cuatro piezas, y conviene saber decir qué hace cada una:

Componente	De qué se encarga
Cliente	Presenta la información, recoge la interacción del usuario, valida lo que puede validar por sí solo y formula la petición. Es siempre el que empieza.
Servidor	Atiende peticiones concurrentes, aplica la lógica, gobierna el acceso al recurso compartido —los datos, casi siempre— y garantiza la integridad y la seguridad. Es el que impone las reglas, porque es el único sitio donde no puede mentir el usuario.
Middleware	La capa de programas que hace posible el diálogo: localiza al servidor, traduce formatos, transporta la petición, gestiona la sesión y devuelve el resultado. Es la pieza invisible y la que da nombre a media docena de tecnologías del tema.
Red	El medio y los protocolos por los que viaja todo. Su latencia y su ancho de banda son, en la práctica, el límite de la arquitectura.

⚠️ La pieza que más se olvida y más se pregunta es el middleware, porque no se ve. Tiene su propio apartado más adelante.

1.3. Cliente ligero, cliente pesado y el reparto de la carga

Lo que de verdad distingue una arquitectura de otra es dónde se ejecuta cada cosa. La clasificación por el peso del cliente:

Tipo	Qué hace el cliente	Consecuencias
Cliente ligero (thin client)	Solo presentación. Toda la lógica y los datos viven en el servidor.	Despliegue trivial —no hay nada que instalar ni actualizar—, hardware barato y control central. A cambio, depende por completo de la red y carga el servidor.
Cliente pesado (fat o rich client)	Presentación y buena parte de la lógica de negocio; a veces incluso acceso directo a los datos.	Respuesta más ágil y menos carga en el servidor, pero hay que desplegar y actualizar en cada puesto, y la lógica repartida es más difícil de mantener coherente.
Cliente híbrido	Presentación con lógica local de validación y ayuda, pero el negocio en el servidor.	Es lo que hoy hace una aplicación web moderna: valida en el navegador para ser ágil y vuelve a validar en el servidor porque lo del navegador no es fiable.

🚨 Esa última frase es una regla de seguridad que cae en los supuestos: la validación del cliente es comodidad, no control. Cualquiera puede saltarse el formulario y llamar al servicio directamente, así que toda comprobación que importe se repite en el servidor.

Y hay una clasificación paralela, la del reparto funcional, que va por dónde se corta la aplicación entre las dos partes: presentación distribuida, presentación remota, lógica distribuida, gestión de datos remota y base de datos distribuida. El orden va de menos a más trabajo en el cliente, y los dos extremos tienen nombre propio: el primero es el terminal de toda la vida y el último es el que reparte incluso los datos entre varios servidores.

1.4. Cómo opera: petición-respuesta, estado y concurrencia

El modo de operación normal es petición-respuesta: el cliente manda una petición, se queda esperando y el servidor contesta. Sobre ese esquema hay tres decisiones que definen el comportamiento del sistema y que el tribunal pregunta por separado.

Síncrono o asíncrono. En el modo síncrono el cliente se bloquea hasta que llega la respuesta: es simple de programar y es lo que hace una consulta normal. En el asíncrono el cliente sigue trabajando y recoge el resultado más tarde, por notificación o preguntando; es lo obligado cuando la operación tarda —un proceso masivo, una firma, un envío a otro organismo— y es la razón de ser de las colas de mensajes.

Con estado o sin estado. Un servidor con estado recuerda entre peticiones quién es el cliente y por dónde iba; uno sin estado trata cada petición como si fuera la primera, y por eso exige que la petición traiga todo lo necesario para atenderla. La consecuencia práctica es de escala: si el servidor no guarda nada, cualquier instancia puede atender cualquier petición y se pueden poner diez detrás de un balanceador sin coordinarlas. Esta es la idea que sostiene REST y la que el tribunal ha preguntado más veces en todo el tema.

Concurrencia. Un servidor atiende a muchos clientes a la vez, y la forma de conseguirlo tiene consecuencias: un hilo por conexión es sencillo pero consume memoria y se ahoga con miles de conexiones; un modelo de eventos con pocos hilos y entrada/salida no bloqueante aguanta mucho más con los mismos recursos. Es exactamente la razón de que la programación asíncrona sea la norma en el desarrollo de servidores modernos.

2. De una capa a n capas

2.1. El punto de partida: centralizado y monolítico

En una arquitectura de una sola capa, presentación, lógica y datos están juntos en el mismo programa y en la misma máquina. Es lo que hace una aplicación de escritorio con su fichero de datos al lado. Ventajas: sencillez y rapidez, porque no hay red por medio. Inconvenientes: no se comparte, no se escala y cualquier cambio obliga a redistribuir el programa entero.

⚠️ Conviene no confundir monolítico con malo. Un monolito bien estructurado por dentro —con sus capas lógicas separadas— es la opción correcta para la mayoría de aplicaciones, y es el punto de partida del que se sale solo cuando hace falta. Esto vuelve a salir en el apartado de microservicios.

2.2. Dos capas

Es el cliente/servidor clásico: un cliente con la presentación y buena parte de la lógica, y un servidor de base de datos que guarda y sirve los datos. El cliente habla directamente con el gestor, normalmente por ODBC o JDBC.

Funciona bien con pocos usuarios y tiene tres problemas que lo hunden al crecer:

• Cada cliente abre su propia conexión a la base de datos. Con quinientos puestos, son quinientas conexiones que el gestor tiene que sostener.
• La lógica de negocio está repartida por los puestos. Un cambio en una regla obliga a redistribuir la aplicación a todos.
• La seguridad queda expuesta: el cliente tiene credenciales de base de datos, y quien controla el puesto controla lo que le manda al gestor.

2.3. Tres capas

La arquitectura de referencia, y la que hay que saber describir con sus responsabilidades exactas:

Capa	De qué responde	De qué NO responde
Presentación	Mostrar, recoger la interacción y validar el formato de lo que entra.	No decide reglas de negocio ni sabe de tablas.
Negocio o aplicación	Las reglas, los cálculos, el flujo del procedimiento y el gobierno de las transacciones.	No sabe si el usuario está en un navegador o en un móvil, ni cómo están guardados los datos.
Datos	Persistir y recuperar, con su integridad.	No decide reglas de negocio.

La regla que la mantiene en pie es que cada capa habla solo con la de debajo. Y lo que se gana es concreto y se pregunta: la lógica está en un solo sitio, así que un cambio normativo se aplica una vez; el gestor de base de datos ve un puñado de conexiones agrupadas en lugar de una por puesto; y la capa de negocio se puede probar sin levantar la interfaz.

Es también la arquitectura que describe Métrica v3 y la que sostiene cualquier aplicación web: el navegador es la presentación, el servidor de aplicaciones el negocio y el gestor los datos.

2.4. N capas o multinivel

El enunciado oficial las llama arquitecturas multicapas, y son estas. Cuando el sistema crece, la capa de negocio se subdivide y aparecen capas nuevas que ya no encajan en las tres clásicas: una capa de servicios que publica la funcionalidad hacia fuera, una capa de integración que habla con otros organismos, una capa de presentación separada por canal —web, móvil, atención presencial—. A eso se le llama arquitectura de n capas o multinivel, y no es otra cosa que el mismo principio llevado más lejos.

Un reparto habitual en una aplicación de la Administración, de fuera hacia dentro: cliente, servidor web que sirve lo estático y hace de proxy inverso, servidor de aplicaciones con la lógica, capa de integración con los servicios comunes, y servidor de base de datos.

2.5. Ventajas e inconvenientes, con la trampa del tribunal

🚨 Esta es la pregunta que el tribunal puso en 2023, y la puso pidiendo la afirmación INCORRECTA sobre las arquitecturas multinivel. Las tres verdaderas eran mayor flexibilidad y modularidad, escalabilidad —facilita añadir recursos para atender a más clientes— y extensibilidad —permite añadir funcionalidad sin afectar a los clientes existentes—. La falsa era «menor coste de comunicaciones, ya que consumen menos ancho de banda».

Y es falsa por una razón que conviene entender y no memorizar: añadir capas añade saltos de red. Lo que en dos capas era una conversación entre el puesto y la base de datos, en cuatro capas son tres conversaciones encadenadas, cada una con su latencia y su serialización. Se gana en todo lo demás y se paga precisamente en comunicaciones. Cualquier opción que atribuya a las capas un ahorro de red o de latencia es falsa por definición.

El balance completo:

A favor	En contra
Modularidad: cada capa se cambia sin tocar las demás.	Más complejidad: más piezas que desplegar, configurar y vigilar.
Escalabilidad: se refuerza solo la capa que se queda corta.	Más latencia y más consumo de red: cada salto cuesta.
Reutilización: la capa de negocio sirve a la web, al móvil y a otro organismo.	Más puntos de fallo y una operación más difícil de diagnosticar.
Seguridad: la base de datos deja de estar expuesta al puesto de usuario.	Coste de infraestructura y de personal especializado.
Mantenimiento: la regla vive en un solo sitio.	Riesgo de capas anémicas que solo reenvían llamadas sin aportar nada.

2.6. Capa lógica y nivel físico no son lo mismo

Una distinción que en castellano se pierde porque las dos palabras inglesas se traducen igual, y que explica enunciados que parecen contradictorios:

• La capa lógica es una división del código por responsabilidades. Existe aunque todo corra en la misma máquina.
• El nivel físico es una división del despliegue: máquinas o procesos distintos, con red entre ellos.

Se puede tener una aplicación de tres capas lógicas desplegada en un solo nivel físico —lo normal en desarrollo— y la misma aplicación repartida en tres niveles en producción, sin cambiar una línea. Es precisamente lo que hace valiosa la separación en capas: permite decidir el despliegue después.

3. El middleware

3.1. Las familias de middleware

Middleware es todo el software que se coloca entre el sistema operativo y la aplicación para que dos programas distribuidos puedan entenderse. Su valor está en lo que le quita al programador: localizar al interlocutor, abrir y cerrar la conexión, traducir los datos entre representaciones distintas, reintentar, controlar la transacción y presentar el resultado como si la llamada hubiera sido local.

Familia	Qué resuelve	Ejemplos
De acceso a datos	Hablar con cualquier gestor con la misma interfaz.	ODBC, JDBC, ADO.NET
De llamada remota	Invocar un procedimiento o un método que está en otra máquina.	RPC, RMI, CORBA, DCOM, gRPC
Orientado a mensajes	Comunicar sin que las dos partes estén vivas a la vez.	Colas y temas de mensajería, JMS, AMQP
Monitores de transacciones	Coordinar operaciones que tocan varios recursos y deben confirmarse o deshacerse juntas.	Monitores TP clásicos, coordinadores de transacciones distribuidas
Servidores de aplicaciones	Alojar componentes y darles transacciones, seguridad y concurrencia.	Tomcat, WildFly, IIS
De integración	Conectar sistemas heterogéneos que no fueron diseñados para hablarse.	Bus de servicios (ESB), pasarelas de API

3.2. Llamada a procedimiento remoto: RPC, RMI, CORBA y DCOM

La idea de la llamada a procedimiento remoto es hacer que invocar algo que está en otra máquina se parezca lo más posible a llamar a una función local. El mecanismo tiene siempre las mismas piezas y conviene saberlas nombrar:

1. El cliente llama a un resguardo o representante local (stub) que tiene la misma firma que el procedimiento real.
2. El resguardo empaqueta los parámetros en un formato transmisible. A ese empaquetado se le llama ordenamiento o marshalling, y resuelve un problema real: dos máquinas pueden guardar los números en distinto orden de bytes.
3. El mensaje viaja por la red hasta el esqueleto del servidor, que desempaqueta y llama al procedimiento de verdad.
4. El resultado vuelve por el mismo camino, empaquetado y desempaquetado otra vez.

Las encarnaciones que hay que reconocer por su nombre:

• RPC: la forma clásica, orientada a procedimientos y no a objetos. 🚨 El tribunal la preguntó en 2023 por un detalle de Windows de 64 bits: las llamadas RPC entre procesos de 32 y 64 bits funcionan tanto en el mismo equipo como entre equipos distintos. Lo que no se puede es cargar en el mismo proceso una biblioteca de vínculos dinámicos de otra arquitectura: un proceso de 64 bits no carga una DLL de 32, ni al revés. La razón es la misma en los dos casos: dentro de un proceso se comparte el espacio de direcciones y el ancho del puntero tiene que coincidir; entre procesos hay un protocolo por medio, y ahí da igual.
• RMI: la versión de Java, orientada a objetos —se invocan métodos sobre objetos remotos— y atada a la plataforma Java en los dos extremos.
• CORBA: el estándar del OMG para invocar objetos remotos entre lenguajes distintos. Su pieza característica es el IDL, el lenguaje de definición de interfaces: se describe la interfaz en un lenguaje neutro y un compilador genera los resguardos para C++, Java o el lenguaje que sea. El intermediario que enruta las peticiones es el ORB.
• DCOM: la respuesta de Microsoft en la misma época, atada a Windows.

⚠️ Todas comparten el mismo talón de Aquiles y por eso los servicios web las desplazaron: necesitan puertos propios y un acuerdo binario estrecho entre las partes, lo que las hace inviables a través de un cortafuegos o de Internet. El servicio web ganó porque viaja por el puerto que ya está abierto —el de HTTP— y en un formato de texto que cualquiera puede leer.

3.3. Middleware orientado a mensajes

Es el que permite que dos sistemas se comuniquen sin estar vivos a la vez. El emisor deja el mensaje en una cola y sigue; el receptor lo recoge cuando puede. Lo que se gana:

• Desacoplamiento temporal: si el receptor está caído, el mensaje espera. La operación no se pierde.
• Amortiguación de picos: la cola absorbe una avalancha que tumbaría al receptor si le llegara de golpe.
• Garantías de entrega: los sistemas de mensajería aseguran que el mensaje llega al menos una vez, y ofrecen colas de mensajes fallidos para los que nadie consigue procesar.

Hay dos modelos de reparto que se preguntan por separado: punto a punto, con una cola y un solo consumidor por mensaje, para repartir trabajo; y publicación-suscripción, con un tema al que se suscriben varios y donde todos reciben una copia, para difundir un suceso. La regla corta: cola para repartir tareas, tema para avisar a varios.

4. Escalabilidad, balanceo y disponibilidad

4.1. Escalar hacia arriba y escalar hacia los lados

	Escalado vertical	Escalado horizontal
En qué consiste	Poner más potencia en la misma máquina: más procesador, más memoria, discos más rápidos.	Poner más máquinas haciendo lo mismo, con un reparto por delante.
A favor	No hay que cambiar la aplicación. Inmediato.	Sin techo teórico, y de paso da tolerancia a fallos: si cae una instancia, quedan las otras.
En contra	Tiene techo y el precio crece más deprisa que la potencia. Y la máquina sigue siendo un punto único de fallo.	Exige que la aplicación no guarde estado local, y añade el balanceador y la coordinación.

La conclusión que hay que llevar aprendida: el escalado horizontal es la vía moderna, y su requisito es la ausencia de estado en el servidor. Aquí es donde encaja la restricción de REST que el tribunal repite: si el servicio no guarda información del cliente entre peticiones, se pueden poner tantas instancias como haga falta.

4.2. El balanceador de carga y el problema de la sesión

El balanceador recibe las peticiones y las reparte entre las instancias disponibles. Los algoritmos que se preguntan por su nombre:

• Turno rotatorio (round robin): una a cada uno, en orden. El más simple.
• Turno rotatorio ponderado: igual, pero dando más peso a las máquinas más potentes.
• Menor número de conexiones: a la instancia que menos tenga abiertas. Va mejor cuando las peticiones duran cosas muy distintas.
• Por origen: se calcula un resumen de la dirección del cliente y siempre le toca la misma instancia.

Además del reparto, el balanceador vigila la salud de cada instancia con una comprobación periódica y saca del reparto a la que no responde. Es lo que convierte el balanceo en alta disponibilidad.

🚨 El problema de la sesión es la consecuencia práctica de todo esto y la pregunta implícita de muchos supuestos: si el servidor guarda la sesión en su propia memoria y la siguiente petición del mismo usuario cae en otra instancia, la sesión no está allí y el usuario aparece desconectado. Hay tres soluciones y conviene saber cuál es la buena:

1. Sesión pegajosa: el balanceador manda siempre al mismo usuario a la misma instancia. Funciona, pero estropea el reparto y, si esa instancia cae, esos usuarios pierden la sesión.
2. Sesión compartida en un almacén externo —una caché en memoria o una base de datos— al que llegan todas las instancias. Es la solución habitual.
3. Sin sesión en el servidor: el estado viaja con la petición, firmado, en un testigo. Es la solución de los servicios REST y la que mejor escala.

4.3. Proxy, proxy inverso y caché

Dos piezas con nombre parecido y sentido opuesto, y el tribunal ha preguntado por las dos:

• El proxy directo se pone delante de los clientes: los equipos de la organización salen a Internet a través de él. Sirve para controlar y filtrar la navegación, y para cachear lo que muchos piden, ahorrando ancho de banda. 🚨 En 2023 el tribunal preguntó qué producto puede hacer de proxy-caché con HTTP, HTTP/2 y HTTPS, y la respuesta era SQUID. Los tres distractores eran herramientas reales de otra cosa: una base de datos de series temporales, un panel de visualización de métricas y un sistema de monitorización. La regla para descartar: si el nombre suena a monitorizar o a pintar gráficas, no es un proxy.
• El proxy inverso se pone delante de los servidores: el cliente cree que habla con él y él reparte por dentro. Es donde suelen vivir el cifrado TLS, la compresión, la caché de respuestas, el balanceo y el filtrado de seguridad. Un servidor web como Apache o nginx delante de un servidor de aplicaciones está haciendo justo esto.

Y la caché, que atraviesa todo el tema: guardar la respuesta para no volver a calcularla. Puede estar en el navegador, en un proxy intermedio, en el proxy inverso o dentro de la aplicación. Su problema no es guardar, es invalidar: saber cuándo lo guardado ha dejado de ser cierto. Por eso HTTP dedica cabeceras enteras a decir cuánto vale una respuesta y cómo comprobar si ha cambiado.

4.4. Agrupamiento y alta disponibilidad

Escalar y no caerse son dos objetivos distintos que se consiguen con la misma pieza: el agrupamiento —el clúster—, un conjunto de máquinas que se presentan al exterior como un solo servicio. La diferencia entre los dos objetivos conviene tenerla clara porque el tribunal los cruza:

Objetivo	Qué se busca	Cómo se mide
Escalabilidad	Atender más carga sin degradarse.	Peticiones por segundo, tiempo de respuesta bajo carga.
Alta disponibilidad	Seguir dando servicio aunque algo falle.	Porcentaje de tiempo en servicio: los famosos cuatro o cinco nueves.

Un agrupamiento da las dos cosas a la vez, pero solo si se ha eliminado cada punto único de fallo: de nada sirven cuatro servidores de aplicaciones si el balanceador es uno solo, o si los cuatro atacan a la misma base de datos sin réplica. De ahí que la lista de comprobación sea siempre la misma: balanceador redundante, varias instancias de aplicación, base replicada y, si el servicio es crítico, más de un centro de proceso de datos.

Dos conceptos que acompañan a esto y que se preguntan por su nombre: la conmutación por error, que es el paso automático a la máquina de reserva cuando la principal cae, y el latido, la señal periódica con que las máquinas se vigilan entre sí para detectar esa caída. Y una advertencia: una máquina más potente —escalar hacia arriba— aumenta la capacidad pero no la disponibilidad, porque sigue siendo una sola.

5. Qué es un servicio web

Un servicio web es una funcionalidad que un sistema publica para que otro programa —no una persona— la use a través de la red, con un formato de intercambio acordado y con independencia del lenguaje y de la plataforma de cada extremo. Esa última parte es la clave: el consumidor puede estar escrito en C#, el proveedor en Java, y ninguno de los dos necesita saberlo.

Sus tres rasgos definitorios:

• Interoperabilidad: lo que se comparte es un contrato —qué operaciones hay, qué datos entran y salen—, no una biblioteca.
• Reutilización: el mismo servicio sirve a la aplicación web, a la aplicación móvil y a otro organismo.
• Bajo acoplamiento: cambiar la implementación por dentro no obliga a tocar a quien lo consume, mientras se respete el contrato.

Hay dos grandes familias, cada una con sus protocolos asociados —que es como los nombra el enunciado oficial—, y el resto del tema son ellas dos:

	Servicios web «grandes» (WS-*)	Servicios web REST
Qué son	Un conjunto de protocolos con especificaciones formales del W3C y de OASIS.	Un estilo de arquitectura que aprovecha lo que HTTP ya ofrece.
Mensaje	SOAP, siempre XML.	Lo que se acuerde: normalmente JSON, también XML.
Contrato	WSDL, obligatorio y procesable por máquina.	OpenAPI o similar, recomendable pero no obligatorio.
Dónde vive	Integración entre organismos, servicios comunes, sistemas heredados.	Aplicaciones web y móviles, microservicios, API públicas.

6. La arquitectura orientada a servicios (SOA)

SOA es la idea de construir el sistema de información de una organización como un conjunto de servicios reutilizables y débilmente acoplados, en lugar de como un puñado de aplicaciones cerradas que se copian datos entre sí. Sus principios, que son los que dan las respuestas:

• Contrato normalizado: el servicio se describe formalmente y esa descripción es lo único que el consumidor necesita.
• Bajo acoplamiento y abstracción: por fuera solo se ve el contrato; la implementación es opaca.
• Reutilización y componibilidad: un servicio se usa en varios procesos y varios servicios se combinan en uno mayor.
• Autonomía: el servicio controla su propio entorno de ejecución.
• Ausencia de estado siempre que sea posible, para poder escalar.
• Descubribilidad: el servicio se puede encontrar y entender a partir de metadatos publicados.

6.1. Los cuatro componentes

🚨 Esta es una de las preguntas más repetidas del tema: cayó en 2024 en el modelo A y en el B, dentro del supuesto de la Plataforma de Intermediación de Datos. Los componentes principales de una arquitectura orientada a servicios son cuatro:

Componente	Qué hace
Servicio	La funcionalidad publicada, con su contrato.
Proveedor de servicios	Quien lo implementa y lo publica.
Consumidor de servicios	Quien lo invoca.
Registro de servicios	El directorio donde el proveedor publica su servicio y donde el consumidor lo localiza.

⚠️ El que siempre falta en los distractores es el registro. Los tres señuelos que puso el tribunal lo sustituían por un «orquestador», un «depurador» y un «comparador» de servicios. La forma de no fallar es entender el triángulo: el proveedor publica en el registro, el consumidor busca en el registro y, una vez encontrado, invoca directamente al proveedor. Sin registro no hay descubrimiento, y sin descubrimiento SOA se queda en un montón de servicios que hay que conocer de memoria.

6.2. El bus de servicios, orquestación y coreografía

El bus de servicios empresarial (ESB) es la pieza de integración típica de SOA: un intermediario por el que pasan todas las comunicaciones y que se encarga de enrutar el mensaje al servicio adecuado, transformar el formato entre sistemas que no coinciden, aplicar la seguridad y registrar la traza. Su virtud es que evita el «plato de espaguetis» de conexiones punto a punto entre n sistemas; su defecto, que se convierte en un punto central que hay que dimensionar y del que depende todo.

Y dos palabras que se confunden a propósito en los exámenes:

• Orquestación: hay un director —un proceso central— que llama a los servicios en el orden que toca y gobierna el flujo. Los servicios no saben que forman parte de un proceso mayor.
• Coreografía: no hay director. Cada servicio reacciona a los sucesos que observa y sabe qué le toca hacer. Es más flexible y mucho más difícil de seguir cuando algo falla.

6.3. SOA en la Administración: la PID y el protocolo SCSP

El ejemplo que el tribunal usa una y otra vez es propio de casa. La Plataforma de Intermediación de Datos (PID) permite que un organismo consulte en línea datos que obran en poder de otro —identidad, residencia, títulos, prestaciones— para hacer efectivo el derecho a no aportar documentos. Su arquitectura actual se define como orientada a servicios, y de ahí sale la pregunta de los cuatro componentes.

El protocolo con el que viajan esas consultas es SCSP (Sustitución de Certificados en Soporte Papel), regulado por la Norma Técnica de Interoperabilidad de Protocolos de Intermediación de Datos, que establece que los intercambios se podrán implementar a través de servicios web. Su versión en uso es la 3, y sus piezas se distribuyen como un portfolio: librerías SCSPv3, cliente ligero SCSPv3 y SCSP–WS. 🚨 En 2026 el tribunal preguntó cuál no forma parte de ese catálogo y la respuesta era «SCSP–SOAP»: SOAP es el estilo del mensaje, no un producto.

El otro nombre propio que ha caído es GEISER, el servicio común de registro, cuyos servicios web son de naturaleza SOAP. Volverá a aparecer en el apartado de seguridad.

7. La pila SOAP y las especificaciones WS-*

7.1. SOAP: el sobre y sus partes

SOAP es un protocolo de mensajería basado en XML para intercambiar información estructurada entre sistemas. Su unidad es el sobre (envelope), y su estructura se pregunta por partes:

Parte	Obligatoria	Qué lleva
Envelope (sobre)	Sí	El elemento raíz que envuelve todo el mensaje.
Header (cabecera)	No	Información de control que no es el dato: seguridad, transacción, enrutado, correlación. Es donde se mete WS-Security.
Body (cuerpo)	Sí	El contenido real: la operación que se invoca y sus parámetros, o la respuesta.
Fault (fallo)	No	Va dentro del cuerpo y describe el error: código, motivo y detalle. Es el equivalente al código de estado de REST.

Un mensaje mínimo, para reconocerlo a simple vista:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <!-- seguridad, correlación, transacción -->
  </soap:Header>
  <soap:Body>
    <consultarIdentidad>
      <documentacion>00000000T</documentacion>
    </consultarIdentidad>
  </soap:Body>
</soap:Envelope>

Tres datos que hay que llevar memorizados:

• 🚨 La última versión de SOAP es la 1.2, recomendación del W3C. Los distractores son siempre «SOAP 2.0» y «SOAP 2.1», que no existen. Es la pregunta más barata del apartado.
• 🚨 Los mensajes de SOAP son XML, siempre. Cuando el tribunal preguntó qué se intercambia con una interfaz SOAP de Cl@ve PIN, la respuesta era mensajes XML, con JSON, YAML y RDF de señuelo. SOAP no habla JSON.
• Sus siglas originales significan Simple Object Access Protocol, aunque a partir de la versión 1.2 el W3C dejó de tratarlo como acrónimo porque el protocolo ya no va de acceder a objetos.

SOAP se transporta normalmente sobre HTTP, pero no está atado a él: puede viajar sobre SMTP o sobre una cola de mensajes. Esa independencia del transporte es una de sus diferencias de fondo con REST, que es HTTP.

7.2. WSDL: el contrato

🚨 La definición literal cayó en los dos modelos de 2026, y conviene retenerla tal cual: WSDL 2.0 es un lenguaje XML para describir servicios web, que permite describir el servicio a partir de un modelo abstracto de lo que ofrece. Es una recomendación del W3C.

Lo importante de esa frase es «modelo abstracto», porque explica cómo está organizado el documento: WSDL separa qué hace el servicio de cómo y dónde se llega a él.

Parte	Nivel	Qué describe
Types	Abstracto	Los tipos de datos que se intercambian, normalmente con esquema XML.
Interface (en 1.1, portType)	Abstracto	Las operaciones disponibles y sus mensajes de entrada y salida.
Binding	Concreto	Cómo se invocan: el protocolo y la codificación —SOAP sobre HTTP, por ejemplo—.
Service y endpoint	Concreto	Dónde: la dirección de red en la que escucha.

Esa separación es la que permite publicar el mismo servicio abstracto en dos direcciones distintas o con dos protocolos, sin reescribir el contrato. ⚠️ Y ojo con la nomenclatura, que cambió: lo que en WSDL 1.1 se llamaba portType y port, en 2.0 pasó a llamarse interface y endpoint, y desapareció el elemento de mensaje independiente.

Los tres distractores que el tribunal puso junto a la definición correcta describían, cada uno, otra cosa del temario, y merece la pena saber a quién pertenecen: «un protocolo de mensajería con un sobre y reglas de codificación» es SOAP; «un protocolo de aplicación con métodos GET, POST, PUT, DELETE y códigos de estado» es HTTP; y «un protocolo bidireccional con handshake y framing sobre TCP para tiempo real» es WebSocket. Los cuatro caen en este tema, y esa pregunta es en realidad cuatro preguntas.

7.3. UDDI, WSIL y el registro

UDDI (Universal Description, Discovery and Integration) es la especificación de registro de la pila WS-*: el directorio donde los proveedores publican sus servicios y los consumidores los buscan. Es la materialización del cuarto componente de SOA.

Se organizaba con una metáfora de guía telefónica que a veces se pregunta: páginas blancas con los datos del proveedor, páginas amarillas con la clasificación por categorías y páginas verdes con la información técnica para invocarlo.

🚨 Y su papel en el examen es casi siempre el de distractor. En 2019 el tribunal preguntó cuál NO es una característica de los servicios REST, y la respuesta era precisamente «usa la especificación UDDI para publicar y encontrar información sobre los servicios web expuestos». UDDI pertenece al mundo SOAP; REST no lo usa. En la práctica, además, los registros UDDI públicos se abandonaron: el descubrimiento se hace hoy con catálogos de API y con documentación publicada.

WSIL (Web Services Inspection Language) es la alternativa ligera: en lugar de un registro central, cada proveedor publica en su propio sitio un documento que enumera los servicios que ofrece y dónde están sus descripciones. Registro centralizado frente a inspección distribuida.

7.4. WS-Security y las demás WS-*

Alrededor de SOAP creció una familia de especificaciones —las WS-*— que añaden lo que el protocolo base no cubre. La que hay que saber sí o sí:

🚨 WS-Security es la especificación que añade seguridad al propio mensaje SOAP: firma electrónica, cifrado y transporte de credenciales, todo dentro de la cabecera del sobre. Con ella se firman las peticiones de un servicio web de naturaleza SOAP, y esa es literalmente la pregunta que el tribunal ha puesto tres veces —en 2024, en el modelo A, en el B y en promoción interna— a propósito de la integración con GEISER.

Los distractores de esa pregunta son los que hay que saber descartar, y cada uno falla por una razón distinta:

• SAML es un formato de aserciones de identidad en XML, para llevar la autenticación de un sistema a otro. Resuelve el inicio de sesión único, no la firma de la petición.
• JWT es un testigo compacto, del mundo REST, no del mundo SOAP.
• XML-Encryption es real y va en la familia, pero cifra: hace el contenido ilegible. No firma, y firmar es lo que se pedía. Este es el distractor bueno de la pregunta, y la trampa está en confundir confidencialidad con integridad y autenticidad.

La razón por la que WS-Security existe teniendo HTTPS merece un párrafo, porque es la clave de todo el modelo: HTTPS protege el tramo, WS-Security protege el mensaje. Si la petición atraviesa tres intermediarios antes de llegar a su destino, con HTTPS se descifra y se vuelve a cifrar en cada salto, y cada intermediario lo ve todo. Con WS-Security la firma y el cifrado viajan con el mensaje de punta a punta y siguen siendo válidos al final del recorrido. Se le llama seguridad extremo a extremo frente a seguridad punto a punto, y es lo que hace a SOAP seguir vivo en la integración entre organismos.

El resto de la familia, que basta reconocer: WS-Addressing —direccionamiento independiente del transporte—, WS-ReliableMessaging —garantía de entrega—, WS-AtomicTransaction —transacciones distribuidas— y WS-Policy —declaración de los requisitos del servicio—.

7.5. Del WSDL al código

La ventaja práctica de tener un contrato formal es que las clases se generan solas. 🚨 El tribunal lo preguntó en 2026 con el mandato exacto: para generar las clases Java de los servicios de Notific@ a partir del fichero notifica.wsdl, en un paquete llamado notificaciones, se usa:

wsimport -p notificaciones notifica.wsdl

Los tres distractores eran herramientas reales de la misma caja, y se distinguen por la dirección en la que trabajan:

Herramienta	De qué a qué
wsimport	De WSDL a clases Java. Es la del enunciado.
wsgen	Al revés: de una clase Java anotada a los artefactos del servicio, WSDL incluido.
xjc	De un esquema XML a clases Java. Es la herramienta de JAXB, y trabaja con XSD, no con WSDL.
schemagen	Al revés que la anterior: de clases Java a esquema XML.

La regla que las ordena en dos ejes: import y jota-equis-ce leen, gen escribe; y las de servicio trabajan con WSDL, las de datos con XSD. Además, ojo al modificador: en wsimport el paquete se indica con -p, mientras que -d es el directorio de salida. Dos de los distractores usaban -d justamente para colar el error.

8. REST

8.1. Qué es y qué no es

REST son las siglas de Representational State Transfer, «transferencia de estado representacional», y es el estilo de arquitectura que Roy Fielding describió en su tesis doctoral del año 2000 a partir de cómo funciona la web. Ese origen explica todo lo demás: REST no inventó nada, ordenó lo que HTTP ya hacía.

🚨 Esta es la pregunta que más veces ha caído del tema entero —cuatro convocatorias con distinta redacción— y siempre gira sobre lo mismo. La afirmación correcta de 2026 lo dice tal cual: REST es un conjunto de principios arquitectónicos que se ajusta a las necesidades de las aplicaciones móviles y los servicios web ligeros. Y la de 2024, repetida en tres exámenes: en la arquitectura REST el servicio no almacena información sobre el estado del cliente entre peticiones.

De ahí salen los cuatro errores que el tribunal usa como distractores, y conviene tenerlos fichados porque son siempre los mismos:

• ❌ «REST es un protocolo». No lo es: es un estilo, un conjunto de restricciones de diseño. El protocolo es HTTP. Un distractor de 2026 lo llamaba «protocolo estándar de la capa de aplicación» y otro «protocolo propietario desarrollado por el W3C»; los dos son falsos, y el segundo además por partida doble, porque REST no es propietario ni lo publicó el W3C.
• ❌ «REST no está orientado a recursos». Al revés: el recurso es su unidad central.
• ❌ «La interfaz puede ser HTTP o FTP». Falso. REST se apoya en la semántica de HTTP —sus métodos, sus códigos, sus cabeceras—, y FTP no la tiene. Este distractor de 2024 es el más fino de todos.
• ❌ «Usa UDDI para publicar y encontrar los servicios». Eso es de la pila SOAP, como ya se ha visto.

Y una aclaración de vocabulario que ahorra confusiones: a un servicio que cumple estas restricciones se le llama RESTful. En la práctica, la mayoría de las API que se anuncian como REST cumplen unas cuantas restricciones y no todas.

8.2. Las seis restricciones

Fielding define REST por seis restricciones, cinco obligatorias y una opcional. Saberlas enumeradas contesta cualquier pregunta de «señale la característica que NO corresponde»:

Restricción	Qué impone	Qué se gana
Cliente-servidor	Separar la interfaz del almacenamiento y la lógica.	Cada parte evoluciona por su cuenta.
Sin estado (stateless)	Cada petición lleva toda la información necesaria; el servidor no guarda contexto del cliente entre peticiones.	Escalabilidad horizontal, fiabilidad y visibilidad. Es la restricción estrella del examen.
Cacheable	Cada respuesta debe declarar, explícita o implícitamente, si se puede almacenar y por cuánto tiempo.	Menos tráfico y menos latencia.
Interfaz uniforme	Recursos identificados por URI, manipulados por sus representaciones, mensajes autodescriptivos y navegación por enlaces.	Es la restricción central: lo que permite que cualquier cliente entienda cualquier servicio.
Sistema en capas	El cliente no puede saber si habla con el servidor final o con un intermediario.	Permite meter cachés, balanceadores y pasarelas sin que nadie se entere.
Código bajo demanda (opcional)	El servidor puede enviar código ejecutable que extiende al cliente.	Es la única opcional, y la que casi nadie usa. Suele ser la respuesta a «¿cuál no es obligatoria?».

8.3. Recursos, URI y representaciones

El recurso es cualquier cosa que merezca ser nombrada: un alumno, una solicitud, la colección de expedientes de un año. Se identifica con una URI, y lo que viaja por la red no es el recurso sino una representación suya —en JSON, en XML, en PDF—, negociada entre cliente y servidor.

⚠️ Una precisión que el tribunal ya rozó en una pregunta anulada: URI es Uniform Resource Identifier, «identificador uniforme de recursos», no «único». La URL es el subtipo que además dice dónde está y cómo llegar, y la URN el que solo lo nombra. Toda URL es una URI; lo contrario no.

Las convenciones de diseño de las direcciones, que aparecen en los supuestos:

• Sustantivos en plural, no verbos. Se escribe /alumnos/47, no /obtenerAlumno?id=47. La acción la dice el método HTTP, no la ruta: si la URI lleva un verbo, el diseño no es REST.
• Jerarquía para lo que pertenece: /expedientes/2026-118/documentos.
• Parámetros de consulta para filtrar, ordenar y paginar, no para identificar.
• Versión explícita cuando el contrato tenga que romperse: /v1/alumnos, o mediante una cabecera.

8.4. Los verbos: seguro e idempotente

🚨 Esta pregunta cayó en los dos modelos de 2026 y es de las que se pierden por no tener claras dos palabras. Preguntaba qué método es idempotente pero NO seguro, y la respuesta era PUT.

Las dos propiedades, definidas con precisión:

• Seguro: el método no modifica el estado del servidor. Solo lee. Si un método es seguro, un buscador puede recorrerlo sin causar daño.
• Idempotente: repetir la misma petición varias veces produce el mismo resultado que hacerla una sola. No dice que no cambie nada: dice que repetirla no cambia nada más. Es lo que permite reintentar sin miedo cuando se pierde la respuesta.

Todo método seguro es idempotente —si no cambia nada, repetirlo tampoco—, pero no al revés, y ese «no al revés» es exactamente la pregunta.

Método	Para qué	Seguro	Idempotente
GET	Obtener la representación de un recurso.	✅ Sí	✅ Sí
HEAD	Como GET pero solo las cabeceras, sin cuerpo.	✅ Sí	✅ Sí
OPTIONS	Preguntar qué se puede hacer sobre el recurso.	✅ Sí	✅ Sí
PUT	Sustituir por completo un recurso en una dirección conocida.	❌ No	✅ Sí
DELETE	Borrar el recurso.	❌ No	✅ Sí
POST	Crear un recurso subordinado o disparar un proceso.	❌ No	❌ No
PATCH	Modificar parcialmente un recurso.	❌ No	❌ No, en general
CONNECT	Abrir un túnel a través de un proxy.	❌ No	❌ No

Los dos razonamientos que conviene tener, porque son los que resuelven la pregunta sin memorizar la tabla:

• PUT es idempotente porque manda el recurso completo a una dirección concreta: enviarlo diez veces deja exactamente el mismo recurso que enviarlo una. Y no es seguro porque escribe.
• POST no es idempotente porque crea: enviarlo diez veces crea diez recursos distintos. Es la razón por la que un navegador avisa al recargar una página que vino de un formulario.
• DELETE es idempotente aunque cueste verlo: borrar dos veces deja el recurso igual de borrado. Que la segunda llamada devuelva un 404 no rompe la idempotencia, porque lo que se mide es el estado del servidor, no el código de respuesta.

Y la correspondencia con las cuatro operaciones de datos, que es la que se pregunta en forma de tabla: POST crea, GET lee, PUT actualiza —entero— y DELETE borra, con PATCH para la actualización parcial.

8.5. Los códigos de estado

De aquí han salido seis preguntas oficiales repartidas por todas las convocatorias, así que esta tabla es de las que rentan. Las cinco familias primero:

Familia	Significado	Quién tiene el problema
1xx	Informativas: la petición se ha recibido y el proceso continúa.	Nadie.
2xx	Éxito: recibida, entendida y aceptada.	Nadie.
3xx	🚨 Redirecciones: el cliente tiene que tomar una acción adicional para completar la petición. Esa frase es literal de una pregunta de 2024.	Nadie, aún.
4xx	🚨 Errores del CLIENTE: la solicitud tiene sintaxis incorrecta o no puede procesarse. Cayó en los dos modelos de 2026.	El cliente.
5xx	Errores del SERVIDOR: falló al completar una solicitud aparentemente válida.	El servidor.

Y los códigos concretos que ya han caído o rondan:

Código	Nombre	Cuándo
200	OK	Éxito genérico, con contenido en la respuesta.
201	Created	🚨 El recurso se ha CREADO. Es la respuesta correcta a un POST que registra algo nuevo, y el tribunal la preguntó en los dos modelos de 2026 con 200, 202 y 204 de señuelo. Debe acompañarse de la cabecera Location con la dirección del recurso nuevo.
202	Accepted	Aceptada pero aún no procesada: la operación es asíncrona. Es el distractor bueno del 201.
204	No Content	Éxito sin cuerpo. Típico de un DELETE o de un PUT que no devuelve nada.
301 y 302	Moved Permanently / Found	Redirección permanente y temporal. La permanente es la que se usa para llevar de HTTP a HTTPS.
304	Not Modified	No ha cambiado desde la última vez: usa lo que tienes en caché.
400	Bad Request	La petición está mal formada o no supera la validación.
401	Unauthorized	No te has identificado (o tus credenciales no valen). Pese al nombre, va de autenticación.
403	Forbidden	🚨 Estás identificado pero NO tienes autorización para esto. Cayó en 2024 en los dos modelos, con 401, 405 y 407 de señuelo.
404	Not Found	El recurso no existe.
405	Method Not Allowed	El recurso existe pero no admite ese verbo.
409	Conflict	Choca con el estado actual del recurso.
415	Unsupported Media Type	El formato del cuerpo no se admite.
429	Too Many Requests	🚨 Se ha superado el límite de peticiones. Es la respuesta de la limitación de tasa y cayó en 2026, con 425, 502 y 503 de señuelo.
500	Internal Server Error	Excepción no controlada. Es la avería de verdad.
502	Bad Gateway	Un intermediario recibió una respuesta inválida del servidor de detrás.
503	Service Unavailable	🚨 El servicio NO está disponible: sobrecarga o mantenimiento. Cayó en 2019.
504	Gateway Timeout	El intermediario se cansó de esperar al de detrás.

⚠️ El par 401/403 es la confusión más rentable del apartado, y se resuelve con una frase: 401 es «no sé quién eres», 403 es «sé quién eres y no puedes». Repetir la petición con credenciales arregla un 401 y no arregla nunca un 403.

Y el par 429/503, que el tribunal enfrentó directamente: el 429 señala que ese cliente se ha pasado del límite pactado —los demás siguen atendidos—, mientras que el 503 dice que el servicio entero no está disponible para nadie. El 429 es una decisión de política; el 503, un estado del sistema.

8.6. Madurez y HATEOAS

El modelo de madurez de Richardson clasifica en cuatro niveles lo REST que es realmente una API, y es la forma más limpia de entender qué falta en la mayoría:

• Nivel 0: una sola dirección y un solo verbo; HTTP como mero túnel. Es lo que hace SOAP.
• Nivel 1 · Recursos: varias direcciones, una por recurso, pero todavía un verbo para todo.
• Nivel 2 · Verbos y códigos: se usan los métodos HTTP con su significado y los códigos de estado correctos. Aquí está la inmensa mayoría de las API «REST» reales.
• Nivel 3 · HATEOAS: las respuestas incluyen enlaces a lo que se puede hacer a continuación.

HATEOAS —Hypermedia As The Engine Of Application State— es la parte de la interfaz uniforme que exige que el cliente navegue por enlaces en lugar de construir direcciones a mano, igual que una persona navega una web sin conocer su estructura de antemano. Es la restricción más ignorada y la que Fielding consideraba imprescindible para llamar REST a algo.

8.7. REST frente a SOAP

	SOAP	REST
Qué es	Protocolo con especificación formal	Estilo de arquitectura
Formato	XML obligatorio	JSON, XML, lo que se acuerde
Contrato	WSDL, obligatorio	OpenAPI, opcional
Transporte	HTTP, SMTP, colas…	HTTP, y su semántica
Estado	Puede mantenerlo	Sin estado por definición
Seguridad	WS-Security, extremo a extremo	TLS y testigos, punto a punto
Transacciones	Sí, con WS-AtomicTransaction	No hay estándar
Peso	Verboso; más proceso	Ligero; mejor para móvil
Caché	Difícil: todo va por POST	Nativa, con GET
Dónde manda	Integración entre organismos, banca, sistemas heredados	Web, móvil, microservicios, API públicas

La conclusión honesta, que además es el criterio profesional: REST para lo nuevo y para lo que consume un navegador o un móvil; SOAP donde ya está y donde hacen falta firma en el mensaje, garantía de entrega o transacción distribuida. En la Administración conviven los dos, y por eso el examen pregunta de los dos.

9. Documentar y probar servicios

🚨 Esta pregunta cayó tres veces en 2024 —modelos A, B y promoción interna— y es de las que se aciertan solo si se ha entendido la diferencia entre un estilo y un lenguaje de descripción. Pedía cuál de las opciones NO es válida para documentar servicios web, y la respuesta era REST.

Las otras tres sí lo son, y conviene saber a qué mundo pertenece cada una:

Lenguaje	Para qué familia	Formato
WSDL	Servicios SOAP	XML
OpenAPI (antes Swagger)	Servicios REST. Es el estándar de hecho.	YAML o JSON
RAML	Servicios REST, alternativa a OpenAPI	YAML
API Blueprint	Servicios REST, la menos extendida	Markdown

REST no es un lenguaje de descripción: es el estilo del servicio que se describe. Poner REST en esa lista es como responder «una casa» a la pregunta de con qué se dibuja un plano.

De OpenAPI conviene saber qué aporta, porque es lo que se usa hoy: un documento que describe rutas, parámetros, esquemas de los cuerpos, códigos de respuesta y esquemas de seguridad, y del que se genera automáticamente la documentación navegable, los clientes en varios lenguajes y hasta un servidor simulado para empezar a integrar antes de que el servicio exista.

Y de las herramientas de prueba, la que ha caído: 🚨 Postman. El tribunal preguntó en 2026 con qué tipo de dato hay que enviar el cuerpo de una petición para probar un servicio REST que recibe un JSON, y la respuesta es raw. La lógica de las cuatro opciones:

• raw: el cuerpo se escribe tal cual, eligiendo el subtipo —JSON, XML, texto—. Es la única forma de mandar un JSON literal.
• none: sin cuerpo. Sirve para un GET.
• x-www-form-urlencoded: pares clave-valor codificados como en un formulario HTML clásico. No es JSON.
• GraphQL: un editor específico para consultas GraphQL, que no es lo que se pedía.

Y del mismo apartado, aunque no ha caído todavía: curl para la línea de órdenes, SoapUI para servicios SOAP y las pruebas automatizadas de contrato, que comprueban que el servicio sigue cumpliendo lo que su documento promete.

9.1. Versionar la interfaz sin romper a quien la usa

Una API publicada a terceros tiene un problema que no tiene una aplicación interna: los consumidores no se actualizan cuando uno quiere. De ahí que el versionado no sea un adorno, y que el tribunal preguntara en 2026 qué número hay que subir tras modificar una interfaz.

La regla la da el versionado semántico, con sus tres cifras: la mayor sube cuando el cambio rompe la compatibilidad —se quita un campo, cambia un tipo, desaparece una operación—; la menor, cuando se añade algo y lo anterior sigue valiendo; y el parche, cuando solo se corrige un error sin tocar el contrato.

Y sobre dónde se pone la versión, las tres formas que se usan:

• En la ruta, como un segmento más. Es la más visible y la más extendida, y la que mejor se lee en un registro de trazas.
• En una cabecera propia o mediante el tipo de contenido. Deja las direcciones limpias, a costa de que la versión no se vea en la dirección.
• En un parámetro de la consulta, que es la menos recomendada porque se pierde con facilidad al copiar un enlace.

⚠️ Elegir dónde ponerla es lo de menos: lo que de verdad importa es que las dos versiones convivan durante un plazo anunciado. Retirar la anterior en cuanto sale la nueva rompe a todos sus consumidores a la vez, y por eso se publica una política de obsolescencia con fechas y se avisa con la cabecera correspondiente antes de apagar nada.

10. Seguridad de los servicios web

10.1. Cómo se identifica quien llama

🚨 El tribunal puso en 2026 una cabecera literal y pidió reconocer el mecanismo:

Authorization: Bearer eyJhbG.eyJzdW.KMUFsI

La respuesta es JWT (JSON Web Token), y se reconoce por tres rasgos combinados: la palabra Bearer —«al portador»—, la cadena partida en tres trozos separados por puntos y el hecho de que el primer trozo empiece por eyJ, que es lo que sale al codificar en base 64 una llave abierta seguida de una comilla.

Los cuatro mecanismos que el tribunal enfrentó, ordenados de menos a más:

Mecanismo	Cómo viaja	Qué tiene en contra
Básica	Usuario y contraseña codificados en base 64 en la cabecera de autorización.	Base 64 no es cifrado: se deshace de un vistazo. Solo es admisible sobre TLS, y aun así manda la contraseña en cada petición.
Clave de API	Una cadena fija en una cabecera o en la dirección.	Identifica a la aplicación, no a la persona; no caduca sola y, si se filtra, sirve indefinidamente.
Cookie de sesión	El identificador de sesión, con el estado en el servidor.	Es con estado, así que no encaja con REST ni escala bien, y expone a la falsificación de petición entre sitios.
JWT	Un testigo firmado con cabecera, carga útil y firma.	No se puede revocar antes de que caduque, así que se emite con vida corta y con un mecanismo de renovación.

Las tres partes del JWT —cabecera con el algoritmo, carga útil con las afirmaciones y firma— llevan a la advertencia que más se repite y más se incumple: ⚠️ el contenido va firmado, NO cifrado. Cualquiera que intercepte el testigo puede leerlo entero. Meter en él datos personales es un error, porque el testigo acaba en registros, en cachés y en la barra de direcciones.

Por encima de todo esto, los dos protocolos que se usan cuando hay terceros de por medio: OAuth 2.0, que es un marco de autorización delegada —permite que una aplicación actúe en nombre del usuario sin conocer su contraseña—, y OpenID Connect, que es la capa de autenticación construida encima de OAuth 2.0. La distinción cae con frecuencia: OAuth dice qué puedes hacer, OpenID Connect dice quién eres.

10.2. CORS y el origen cruzado

🚨 Cayó en 2024 en los dos modelos: qué hay que configurar en el servidor para restringir que las únicas peticiones HTTP de origen cruzado iniciadas desde scripts que se acepten procedan del propio frontal. La respuesta es CORS.

Para entenderlo hay que empezar por la regla que CORS relaja: la política del mismo origen, que el navegador aplica de fábrica y que impide que el guion de una página lea la respuesta de otro origen —donde origen es la terna protocolo, dominio y puerto: si cambia cualquiera de los tres, es otro origen—. Es lo que evita que una página maliciosa lea el correo del usuario en otra pestaña.

El problema es que una aplicación moderna tiene el frontal en un sitio y la API en otro, así que hace falta una excepción controlada. CORS (Cross-Origin Resource Sharing) es esa excepción, y lo esencial es quién decide: lo autoriza el SERVIDOR, mediante cabeceras de respuesta, y lo aplica el navegador. Las cabeceras que se reconocen: la que declara el origen permitido, la que enumera los métodos, la que enumera las cabeceras y la que autoriza el envío de credenciales.

Para los métodos que pueden cambiar algo, el navegador manda antes una petición de comprobación previa con el verbo OPTIONS, y solo si la respuesta lo autoriza envía la de verdad.

⚠️ Dos advertencias que separan al que lo ha entendido del que lo ha memorizado: CORS no protege el servidor, protege al usuario del navegador —un programa que llame a la API sin navegador se lo salta entero, porque no hay nadie que aplique la regla—; y autorizar cualquier origen con un comodín anula la protección y además es incompatible con el envío de credenciales.

Los tres distractores de la pregunta son cabeceras y tecnologías reales de seguridad web, y hay que saber qué hace cada una: HSTS obliga al navegador a usar siempre HTTPS con ese dominio; CSP declara de qué orígenes se puede cargar cada tipo de recurso y es una defensa contra el guionado entre sitios; y TLS es el cifrado del canal. Ninguna decide quién puede llamar desde otro origen.

10.3. Limitación de peticiones

La limitación de tasa (rate limiting) fija cuántas peticiones puede hacer un cliente en un periodo. Sirve contra la denegación de servicio, contra el abuso de una API pública y contra los errores de programación que llaman en bucle. 🚨 Cuando se alcanza el límite se responde 429 Too Many Requests, como ya se ha visto, y lo correcto es acompañarlo de la cabecera Retry-After, que dice cuándo se puede volver a intentar.

Se puede limitar por dirección de origen, por clave de API, por usuario autenticado o por combinación, y suele aplicarse en la pasarela o en el proxy inverso, no dentro de la aplicación: si la petición llega hasta el código, ya ha consumido recursos.

10.4. HTTPS, TLS y el puerto 80

Dos preguntas de 2024, las dos con la recomendación del Centro Criptológico Nacional por medio, y las dos repetidas en tres exámenes.

🚨 La primera: versión de TLS. La versión mínima aceptable es la 1.2 y se recomienda usar la 1.3. Las versiones 1.0 y 1.1 están retiradas por inseguras, igual que todo SSL. La regla mnemotécnica: 1.2 el suelo, 1.3 el objetivo.

De TLS 1.3 conviene saber qué mejoró, porque también ha caído: completa el saludo en un solo viaje de ida y vuelta —frente a los dos de la 1.2—, lo que reduce la latencia, y de paso elimina los algoritmos antiguos y los modos de cifrado que se habían demostrado débiles.

🚨 La segunda: qué hacer con el puerto 80 en un servidor web publicado por HTTPS. La recomendación es mantener abierto el puerto TCP/80 y configurar el servidor para que redirija automáticamente de HTTP a HTTPS. La razón es de servicio, no de seguridad: quien teclea la dirección sin protocolo llega por el 80, y si está cerrado ve un error en lugar de la web. Cerrarlo no protege nada —el atacante no necesita el 80— y rompe la experiencia. La redirección se completa con HSTS, que hace que el navegador ni siquiera intente el HTTP la próxima vez.

🚨 Y la tercera, del mismo bloque: qué parte del certificado necesita el navegador para establecer la conexión segura. La respuesta es la clave pública del certificado del sitio web. La clave privada no sale nunca del servidor: si saliera, el certificado dejaría de valer para nada. Lo que ocurre en el saludo es que el navegador comprueba el certificado contra las autoridades en las que confía y usa la clave pública para acordar de forma segura una clave de sesión simétrica, que es la que cifra de verdad el tráfico porque es mucho más rápida.

10.5. El cortafuegos de aplicación web

🚨 En 2023 el tribunal preguntó qué módulo hay que implantar para filtrar y monitorizar el tráfico HTTP desde Internet hacia los servidores web, y la respuesta era WAF, Web Application Firewall. Los otros tres nombres —«Web Administration Tool», «Virtual Firewall Network», «Web Firewall Layer 7»— no existen, y ese es el tipo de pregunta que se acierta reconociendo el término real.

La diferencia que conviene tener clara: un cortafuegos de red decide por dirección y puerto —deja pasar el 443 y bloquea el resto— y no mira lo que va dentro. Un WAF trabaja en la capa de aplicación: entiende HTTP, lee las peticiones y bloquea las que encajan con patrones de ataque —inyección de SQL, guionado entre sitios, recorrido de directorios—. Se usa como refuerzo, nunca como sustituto de programar bien: un WAF filtra lo conocido, y la validación en el servidor es lo que protege de lo demás.

Y en la misma familia, la orden que ha caído para revisar el cortafuegos de una máquina Linux: 🚨 para comprobar si el servicio HTTPS está permitido en la zona pública se usa

firewall-cmd --zone=public --list-services

Los distractores fallaban por sintaxis o por objeto: uno pedía las zonas activas con un valor que ese modificador no admite, otro listaba puertos en lugar de servicios —y HTTPS aquí es un servicio con nombre, no un número— y el último mezclaba una herramienta distinta con una tabla que no toca.

11. Microservicios

11.1. Del monolito a los microservicios

Una arquitectura de microservicios divide la aplicación en servicios pequeños, autónomos y desplegables por separado, cada uno responsable de una capacidad de negocio y con su propia base de datos. Ese último detalle es el que de verdad los define: si dos servicios comparten tablas, no son independientes por mucho que se desplieguen aparte.

	Monolito	Microservicios
Despliegue	Todo junto, una unidad.	Cada servicio por su cuenta y a su ritmo.
Escalado	Se replica la aplicación entera, aunque solo se sature una parte.	Se replica solo el servicio que lo necesita.
Tecnología	Una pila para todo.	Cada servicio puede usar la suya.
Fallo	Un error grave puede tumbarlo todo.	Queda acotado… si se ha diseñado para ello.
Transacciones	Una transacción de base de datos y listo.	No hay transacción global: hacen falta patrones de compensación.
Operación	Sencilla: una cosa que vigilar.	Compleja: decenas de piezas, trazas distribuidas, versiones cruzadas.

11.2. Las piezas que aparecen siempre

• Pasarela de API (API Gateway): la puerta única hacia fuera. Enruta al servicio que toca y concentra lo transversal: autenticación, limitación de tasa, registro y, a veces, composición de respuestas. Evita que el cliente tenga que conocer la topología interna.
• Descubrimiento de servicios: un registro donde cada instancia se da de alta al arrancar, para que las demás la encuentren sin direcciones fijas. Es el mismo papel que el registro de SOA, resuelto con otra tecnología.
• Configuración centralizada: los valores por entorno en un servicio aparte, no en cada imagen.
• Cortacircuitos (circuit breaker): cuando un servicio empieza a fallar, deja de llamársele durante un tiempo en lugar de insistir. Evita el fallo en cascada, que es la forma habitual en que se cae un sistema de microservicios: uno se atasca, los que le llaman agotan sus hilos esperando y se atascan también.
• Trazabilidad distribuida: un identificador de correlación que viaja con la petición por todos los servicios. Sin él, diagnosticar es imposible.
• Malla de servicios (service mesh): una capa que resuelve el cifrado entre servicios, el reintento y la observación fuera del código de la aplicación.

11.3. Contenedores y orquestación

Los microservicios se despliegan en contenedores: paquetes que llevan dentro la aplicación y todo lo que necesita para ejecutarse, aislados entre sí pero compartiendo el núcleo del sistema operativo. Frente a una máquina virtual, que lleva un sistema operativo entero, el contenedor es mucho más ligero y arranca en segundos.

Y como pasan de unos pocos a cientos, hace falta un orquestador. Kubernetes es el estándar: decide en qué máquina corre cada contenedor, lo reinicia si muere, lo escala según la carga, le da una dirección estable y hace el despliegue progresivo.

🚨 De él ha caído un dato muy concreto, en los dos modelos de 2024: los protocolos que se pueden usar en un servicio de Kubernetes son SCTP, TCP —por defecto— y UDP. Merece la pena entender por qué, porque explica los tres distractores: son protocolos de transporte, no de aplicación. HTTP, HTTPS, FTP, SSH y SFTP son de aplicación y viajan encima de TCP, así que no pueden ser lo que un servicio declara. La regla para descartar: si la opción nombra HTTP o SSH, está confundiendo la capa.

De la misma familia, aunque no ha caído todavía: el pod como unidad mínima que Kubernetes despliega —uno o varios contenedores que comparten red y almacenamiento—, el despliegue que mantiene un número de réplicas y el servicio que les da una dirección estable.

11.4. Cuándo NO conviene

🚨 Y una especificación que el tribunal preguntó en 2023: para desarrollar un microservicio alineado con el Jakarta EE Core Profile, la especificación de la comunidad indicada es MicroProfile. Los distractores eran especificaciones reales de Jakarta EE pero de otra cosa: autenticación, procesos por lotes y conectores a sistemas externos. MicroProfile es precisamente el conjunto de especificaciones que añade a la plataforma lo que los microservicios necesitan: configuración, tolerancia a fallos, métricas, comprobaciones de salud, trazado y testigos JWT.

Dicho todo lo anterior, la respuesta profesional que conviene tener por escrito: los microservicios resuelven un problema de organización, no de tecnología. Merecen la pena cuando hay varios equipos que necesitan desplegar sin coordinarse y cuando partes distintas del sistema tienen necesidades de escala muy distintas. Para una aplicación que mantiene un equipo pequeño, un monolito bien estructurado es mejor decisión: da todas las ventajas de la separación en capas sin pagar la operación distribuida, las transacciones repartidas ni el diagnóstico a través de diez servicios.

12. Otros estilos y protocolos

El tribunal los usa sobre todo como distractores bien construidos, así que hay que reconocerlos por lo que hacen:

Tecnología	Qué es	Cuándo se elige
gRPC	Llamada a procedimiento remoto moderna, sobre HTTP/2, con contrato en protocol buffers y mensajes binarios.	Comunicación entre servicios internos, donde importa el rendimiento y no hace falta que un navegador lo consuma.
GraphQL	Lenguaje de consulta para API: un solo punto de entrada y el cliente pide exactamente los campos que quiere.	Cuando hay muchos clientes con necesidades distintas y REST obliga a pedir de más o a hacer muchas llamadas.
WebSocket	🚨 Protocolo de comunicación bidireccional con saludo y tramado sobre TCP, para tiempo real. Esa definición es literal de un distractor de 2026.	Chat, notificaciones en vivo, paneles que se actualizan solos. Es con estado: la conexión permanece abierta.
Sucesos enviados por el servidor	Un canal unidireccional del servidor al cliente sobre HTTP normal.	Cuando solo hace falta que el servidor avise, sin respuesta. Más simple que WebSocket.
Webhook	La inversión del papel: el servidor llama al cliente a una dirección que este le dio, cuando ocurre algo.	Integración entre sistemas sin que uno tenga que estar preguntando.

La distinción que resuelve las preguntas de este apartado es quién empieza y cuánto dura la conexión: en REST empieza el cliente y la conexión muere con la respuesta; en WebSocket empieza el cliente pero la conexión queda abierta y hablan los dos; en los sucesos del servidor queda abierta pero habla uno solo; y en el webhook empieza el servidor.

13. El protocolo HTTP por dentro

13.1. La petición y la respuesta

Todo lo anterior descansa sobre HTTP, así que conviene saber describirlo. Es un protocolo de capa de aplicación, de petición-respuesta y sin estado: cada petición llega sola y el servidor no recuerda la anterior. Todo el mecanismo de sesiones, cookies y testigos existe precisamente para compensar esa ausencia de memoria.

Una petición tiene tres partes:

GET /alumnos/47 HTTP/1.1          <- línea inicial: método, ruta y versión
Host: sede.ejemplo.gob.es          <- cabeceras
Accept: application/json
Authorization: Bearer eyJhbG...

                                   <- línea en blanco y, si lo hay, cuerpo

Y una respuesta, las mismas tres con la línea inicial cambiada:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300

{"id":47,"nombre":"Ana"}

La negociación de contenido es la pieza que permite que el mismo recurso se sirva en varios formatos: el cliente dice en Accept qué entiende y el servidor responde con lo que ha elegido en Content-Type. Es la implementación práctica de la distinción entre recurso y representación.

13.2. Cabeceras que se preguntan

Cabecera	Para qué
Host	A qué sitio va la petición. Es lo que permite alojar muchos sitios en la misma dirección.
Content-Type y Accept	Formato que se envía y formatos que se aceptan.
Authorization	Las credenciales. Es donde va el Bearer del JWT.
Cache-Control, ETag, Last-Modified	Cuánto vale la respuesta y cómo comprobar si ha cambiado sin volver a traerla.
Location	Dónde está el recurso: en una redirección, el destino; en un 201, la dirección del recurso recién creado.
Set-Cookie y Cookie	El servidor pone la cookie; el navegador la devuelve en las siguientes peticiones.
Strict-Transport-Security	HSTS: obliga al navegador a usar HTTPS con ese dominio.
Content-Security-Policy	De qué orígenes puede cargarse cada tipo de recurso. Defensa contra el guionado entre sitios.
Retry-After	Cuándo volver a intentarlo. Acompaña al 429 y al 503.

13.3. Cookies: HttpOnly, Secure y SameSite

🚨 El tribunal preguntó en 2026 por el propósito técnico del atributo HttpOnly en una cabecera Set-Cookie, y la respuesta es que impide que los scripts del lado del cliente accedan a la cookie, mitigando ataques XSS.

Los tres distractores eran, cada uno, otro atributo real de la misma cabecera, y esa es la trampa: la pregunta no se contesta descartando por absurdo, sino sabiéndose los cuatro.

Atributo	Qué hace exactamente
HttpOnly	El guion de la página no puede leerla. Si un atacante consigue inyectar código, no podrá robar la cookie de sesión. Es la respuesta correcta.
Secure	La cookie solo se envía por conexión cifrada. Ese era el primer distractor.
Domain	Para qué dominio y subdominios vale. Era el tercer distractor.
Expires / Max-Age	Cuánto dura. Sin ninguno de los dos, la cookie es de sesión y muere al cerrar el navegador: eso era el cuarto distractor.
SameSite	Si la cookie se envía en peticiones que vienen de otro sitio. Es la defensa principal contra la falsificación de petición entre sitios.

La forma de no confundir los dos primeros, que es lo que falla: Secure protege la cookie EN EL CAMINO —que no viaje en claro— y HttpOnly la protege EN EL NAVEGADOR —que no la lea un guion—. Son amenazas distintas y se ponen las dos.

Y la conexión con el otro ataque que ha caído: 🚨 lo que OWASP recomienda para prevenir el guionado entre sitios (XSS) es validar y escapar correctamente los datos antes de mostrarlos en el navegador. Los distractores de esa pregunta —usar HTTP en lugar de HTTPS, poner los servidores en redundancia física, guardar los datos en un gestor concreto— no tienen nada que ver, y uno de ellos es directamente lo contrario de una buena práctica. La regla de fondo: el XSS se ataja donde se PINTA el dato, no donde se guarda.

13.4. HTTP/1.1, HTTP/2 y HTTP/3

Versión	Qué cambió
HTTP/1.1	Texto plano, una petición por conexión a la vez —con conexiones persistentes para no reabrirlas—. Su límite es el bloqueo por cabeza de línea: una respuesta lenta retiene a las de detrás.
HTTP/2	Binario y multiplexado: muchas peticiones y respuestas simultáneas sobre una sola conexión TCP. Añade compresión de cabeceras y priorización. Elimina el bloqueo en la capa HTTP, pero no en TCP: si se pierde un paquete, se paran todos los flujos.
HTTP/3	Sobre QUIC, que va encima de UDP y lleva el cifrado integrado. Al no depender del orden de TCP, una pérdida solo afecta al flujo afectado, y el establecimiento de conexión es más rápido. Es lo que mejor se comporta en redes móviles.

14. Cuadros para memorizar

Lo que hay que saber de memoria, sin razonar.

Pregunta	Respuesta
Última versión de SOAP	1.2
Qué es WSDL 2.0	Lenguaje XML del W3C para describir servicios web a partir de un modelo abstracto
Qué es REST	Conjunto de principios arquitectónicos; sin estado; orientado a recursos; sobre HTTP
Componentes de SOA	Servicio · Proveedor · Consumidor · Registro
Con qué se firma una petición SOAP	WS-Security
Mensajes de una interfaz SOAP	XML
Qué NO documenta servicios web	REST (sí lo hacen WSDL, OpenAPI/Swagger y RAML)
Idempotente pero NO seguro	PUT
Recurso creado	201 Created
Identificado pero sin permiso	403 (sin identificar es 401)
Límite de peticiones superado	429
Servicio no disponible	503
Familia 3xx	Redirecciones: el cliente debe hacer algo más
Familia 4xx	Errores del cliente
De WSDL a clases Java	wsimport -p paquete fichero.wsdl
Cuerpo JSON en Postman	raw
Restringir peticiones de origen cruzado	CORS
Atributo que impide leer la cookie desde un guion	HttpOnly
Prevenir XSS, según OWASP	Validar y escapar los datos antes de mostrarlos
TLS según el CCN	Mínimo 1.2, recomendado 1.3
Puerto 80 con web en HTTPS	Mantenerlo y redirigir automáticamente a HTTPS
Qué necesita el navegador del certificado	La clave pública
Filtrar tráfico HTTP hacia los servidores web	WAF
Proxy-caché con HTTP, HTTP/2 y HTTPS	SQUID
Protocolos de un servicio de Kubernetes	SCTP, TCP (por defecto) y UDP
Especificación para microservicios con Jakarta EE Core Profile	MicroProfile
Falso sobre las arquitecturas multinivel	Que consuman menos ancho de banda

Los seis pares que el tribunal confunde a propósito.

Par	Cómo se separan
401 / 403	«No sé quién eres» / «Sé quién eres y no puedes»
429 / 503	Este cliente se pasó / el servicio entero está caído
201 / 202	Ya está creado / lo he aceptado pero aún no lo he hecho
Secure / HttpOnly	Protege la cookie en el camino / la protege del guion
Orquestación / coreografía	Hay director / cada uno reacciona por su cuenta
Proxy / proxy inverso	Delante de los clientes / delante de los servidores

15. Lo que ya ha preguntado el tribunal

Convocatoria	Qué preguntó	Respuesta oficial
2026 (A y B)	Finalidad de WSDL 2.0 según el W3C	Lenguaje XML para describir servicios web a partir de un modelo abstracto
2026 (A y B)	Método HTTP idempotente pero no seguro	PUT
2026 (A y B)	Clase de códigos de error del cliente	4xx
2026 (A y B)	Código para un recurso creado por un servicio REST	201 Created
2026 (A y B)	Controlador REST correcto en Spring Boot	Clase anotada como controlador REST con la anotación de GET sobre la ruta
2026 (A y B)	Recomendación de OWASP contra XSS	Validar y escapar los datos antes de mostrarlos
2026 (A y B)	Comprobar servicios permitidos en una zona del cortafuegos	firewall-cmd --zone=public --list-services
2026 (extra.)	Última versión de SOAP	1.2
2026 (extra.)	Afirmación correcta sobre REST	Conjunto de principios arquitectónicos para móviles y servicios ligeros
2026 (extra.)	Propósito de HttpOnly en Set-Cookie	Impedir que los guiones del cliente accedan a la cookie
2026 (extra.)	Generar clases Java desde un WSDL	wsimport -p notificaciones notifica.wsdl
2026 (extra.)	Cabecera Authorization: Bearer eyJ…	JWT
2026 (extra.)	Tipo de cuerpo en Postman para un JSON	raw
2026 (extra.)	Código al alcanzar el límite de peticiones	429
2026 (extra.)	Producto que NO está en el portfolio SCSPv3	SCSP–SOAP
2024 (A, B y PI)	Afirmación correcta sobre servicios web REST	El servicio no almacena el estado del cliente entre peticiones
2024 (A, B y PI)	Qué NO sirve para documentar servicios web	REST
2024 (A, B y PI)	Con qué firmar peticiones SOAP hacia GEISER	WS-Security
2024 (A y B)	Componentes principales de la arquitectura SOA de la PID	Servicio, proveedor, consumidor y registro
2024 (A y B)	Código si el usuario no tiene autorización	403
2024 (A y B)	Restringir peticiones de origen cruzado desde guiones	CORS
2024 (A y B)	Protocolos para servicios en Kubernetes	SCTP, TCP (por defecto) y UDP
2024 (A y B)	Qué hacer con el puerto 80 según el CCN	Mantenerlo y redirigir a HTTPS
2024 (A, B y PI)	Versión de TLS mínima y recomendada según el CCN	Mínima 1.2, recomendada 1.3
2024 (PI)	Significado de los códigos 3xx	Redirecciones: el cliente debe hacer algo más
2023 (LI y PI)	Afirmación INCORRECTA sobre arquitecturas multinivel	Que consuman menos ancho de banda
2023 (LI y PI)	Qué parte del certificado necesita el navegador	La clave pública
2023 (LI y PI)	Proxy-caché con HTTP, HTTP/2 y HTTPS	SQUID
2023 (PI)	Mensajes de una interfaz SOAP de Cl@ve PIN	XML
2023 (LI)	Módulo para filtrar tráfico HTTP hacia los servidores web	WAF
2023 (LI)	Especificación para microservicios con Jakarta EE Core Profile	MicroProfile
2023 (LI)	RPC entre procesos de 32 y 64 bits en Windows	Funciona en el mismo equipo y entre equipos distintos
2019	Qué NO es característica de los servicios REST	Usar UDDI para publicar y encontrar servicios
2019	Código de error de servicio no disponible	503

Y las dos que anuló. En 2023 anuló una sobre REST cuyas cuatro opciones eran defendibles —incluida la que decía que URI significa Unique en lugar de Uniform, que es un error real pero no el único de la pregunta— y otra que pedía un protocolo de seguridad de las comunicaciones HTTP con TLS, SSL y STARTTLS entre las opciones. Sirven de aviso: cuando dos opciones parecen igual de correctas, a veces es porque lo son.