B3-T7: Servicios Web y Arquitecturas Orientadas a Servicios
Este tema combina estándares W3C/OASIS (SOAP/WSDL) con la arquitectura REST y tecnologías modernas (GraphQL, gRPC). Las preguntas suelen pedir diferenciar SOAP de REST o identificar partes del WSDL. JWT aparece cada vez más.
EVOLUCIÓN DE LA COMPUTACIÓN DISTRIBUIDA
Fuente: W3C Web Services Architecture (w3.org/TR/ws-arch), RFCs IETF, especificaciones OASIS.
| Tecnología | Época | Protocolo | Características |
|---|---|---|---|
| RPC (Remote Procedure Call) | 1980s | Binario propietario | Llamadas remotas como si fueran locales. Acoplamiento fuerte |
| CORBA (OMG) | 1990s | IIOP (sobre TCP) | IDL para definir interfaces. Multi-lenguaje. Complejo |
| DCOM (Microsoft) | 1990s | Binario propietario | COM distribuido. Solo Windows |
| RMI (Java) | 1997 | JRMP | RPC nativo de Java. Solo JVM |
| SOAP (W3C) | 2000 | XML sobre HTTP | Estándar abierto, interoperable, pesado |
| REST (Roy Fielding) | 2000 | HTTP nativo | Arquitectura ligera, recursos con URIs |
| GraphQL (Facebook) | 2015 | HTTP (JSON) | Cliente define qué datos quiere |
| gRPC (Google) | 2015 | HTTP/2 (Protobuf) | Binario, streaming bidireccional, alto rendimiento |
COMPARATIVA DE PARADIGMAS
| Aspecto | SOAP | REST | GraphQL | gRPC |
|---|---|---|---|---|
| Formato datos | XML (obligatorio) | JSON, XML, texto | JSON | Protocol Buffers (binario) |
| Transporte | HTTP, SMTP, JMS | HTTP | HTTP | HTTP/2 |
| Contrato | WSDL | OpenAPI/Swagger (opcional) | Schema (obligatorio) | .proto (obligatorio) |
| Estado | Puede ser stateful | Stateless | Stateless | Stateless |
| Tipado | Fuertemente tipado | Débilmente tipado | Fuertemente tipado | Fuertemente tipado |
| Rendimiento | Pesado (XML parsing) | Ligero | Ligero | Muy alto (binario) |
| Caso de uso | Banca, seguros, legacy | APIs web, móviles | SPAs con datos complejos | Microservicios internos |
SOAP (Simple Object Access Protocol)
Fuente: W3C SOAP 1.2 Specification (w3.org/TR/soap12). Estándar W3C desde 2003.
| Parte del mensaje SOAP | Función |
|---|---|
| Envelope | Elemento raíz XML. Envuelve todo el mensaje |
| Header | Opcional. Metadatos: seguridad (WS-Security), transacciones, routing |
| Body | Obligatorio. Contenido del mensaje: request o response |
| Fault | Dentro del Body. Información de error: faultcode, faultstring, detail |
| Estilo de binding | Descripción |
|---|---|
| Document/Literal | Preferido (WS-I). El body contiene un documento XML completo. Validable con XSD |
| RPC/Encoded | El body es una llamada a procedimiento con parámetros codificados. Legacy, no recomendado |
WSDL (Web Services Description Language)
Fuente: W3C WSDL 1.1 (w3.org/TR/wsdl) y WSDL 2.0 (w3.org/TR/wsdl20).
| Elemento WSDL 1.1 | Función | Equivalente WSDL 2.0 |
|---|---|---|
| types | Esquema XSD de los tipos de datos | types |
| message | Define parámetros de entrada/salida | (integrado en interface) |
| portType | Operaciones (métodos) del servicio | interface |
| binding | Protocolo + formato (SOAP, HTTP, estilo) | binding |
| service | Dirección (URL) del endpoint | service + endpoint |
Pregunta clásica: Las 5 partes del WSDL son types, message, portType, binding, service. En WSDL 2.0, message desaparece y portType se renombra a interface.
WS-* (Especificaciones complementarias)
| Especificación | Organismo | Función |
|---|---|---|
| WS-Security | OASIS | Seguridad: tokens (UsernameToken, X.509, SAML), firma XML, cifrado XML |
| WS-ReliableMessaging | OASIS | Entrega garantizada de mensajes (at-least-once, exactly-once, in-order) |
| WS-AtomicTransaction | OASIS | Transacciones distribuidas ACID entre servicios |
| WS-Addressing | W3C | Información de routing independiente del transporte (ReplyTo, FaultTo) |
| WS-Policy | W3C | Políticas del servicio (requisitos de seguridad, QoS) |
| WS-I Basic Profile | WS-I | Perfil de interoperabilidad: reglas para SOAP/WSDL interoperable |
| UDDI | OASIS | Registro/directorio de servicios (páginas blancas, amarillas, verdes). Obsoleto |
JAX-WS (API Java para SOAP)
| Anotación | Función |
|---|---|
@WebService | Marca clase como servicio SOAP |
@WebMethod | Expone método como operación SOAP |
@WebParam | Nombra parámetros en el WSDL |
@WebResult | Nombra el resultado en el WSDL |
@SOAPBinding | Define estilo (Document/RPC) y uso (Literal/Encoded) |
REST (Representational State Transfer)
Fuente: Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (2000). Tesis doctoral pública de UC Irvine. RFC 9110 (HTTP Semantics).
| Restricción REST | Descripción |
|---|---|
| Client-Server | Separación de responsabilidades entre cliente y servidor |
| Stateless | Cada petición contiene toda la información necesaria. El servidor no guarda estado de sesión |
| Cacheable | Las respuestas deben indicar si son cacheables (Cache-Control, ETag) |
| Uniform Interface | Interfaz uniforme: recursos identificados por URI, representaciones, mensajes auto-descriptivos, HATEOAS |
| Layered System | Capas intermedias (proxies, gateways, CDN) transparentes para el cliente |
| Code on Demand (opcional) | El servidor puede enviar código ejecutable al cliente (JavaScript) |
VERBOS HTTP EN REST
| Verbo | CRUD | Idempotente | Safe | Ejemplo URI | Body |
|---|---|---|---|---|---|
| GET | Read | Sí | Sí | GET /api/users/42 | No |
| POST | Create | No | No | POST /api/users | Sí |
| PUT | Update (completo) | Sí | No | PUT /api/users/42 | Sí |
| PATCH | Update (parcial) | No* | No | PATCH /api/users/42 | Sí |
| DELETE | Delete | Sí | No | DELETE /api/users/42 | No |
| HEAD | Metadatos | Sí | Sí | HEAD /api/users/42 | No |
| OPTIONS | Capacidades | Sí | Sí | OPTIONS /api/users | No |
Idempotente = repetir la operación produce el mismo resultado. GET, PUT, DELETE son idempotentes. POST no lo es (cada call puede crear un nuevo recurso).
CÓDIGOS DE ESTADO HTTP
| Rango | Categoría | Códigos clave |
|---|---|---|
| 1xx | Informativo | 100 Continue, 101 Switching Protocols |
| 2xx | Éxito | 200 OK, 201 Created, 204 No Content |
| 3xx | Redirección | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | Error del cliente | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict, 429 Too Many Requests |
| 5xx | Error del servidor | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable |
HATEOAS y Modelo de Madurez de Richardson
| Nivel | Nombre | Descripción |
|---|---|---|
| 0 | The Swamp of POX | Un solo URI, un solo verbo (POST). Básicamente RPC sobre HTTP |
| 1 | Resources | Múltiples URIs para distintos recursos, pero un solo verbo |
| 2 | HTTP Verbs | Uso correcto de GET, POST, PUT, DELETE + códigos de estado |
| 3 | HATEOAS | Las respuestas incluyen hipervínculos a acciones posibles (Hypermedia As The Engine Of Application State) |
Tip examen: HATEOAS es el nivel máximo de madurez REST. El cliente navega la API siguiendo links, sin conocer URIs de antemano.
SEGURIDAD EN APIs REST
| Mecanismo | Cómo funciona | Estándar |
|---|---|---|
| API Key | Token estático en header o query param | No estandarizado |
| HTTP Basic | Authorization: Basic base64(user:pass) | RFC 7617 |
| OAuth 2.0 | Framework de autorización delegada. Flujos: Authorization Code, Client Credentials, PKCE | RFC 6749, 6750 |
| JWT | Token autónomo firmado (JWS) u opcionalmente cifrado (JWE) | RFC 7519 |
| OpenID Connect | Capa de identidad sobre OAuth 2.0. ID Token (JWT) | openid.net |
| mTLS | Autenticación mutua con certificados X.509 | RFC 8446 (TLS 1.3) |
JWT (JSON Web Token)
Fuente: RFC 7519 (JWT), RFC 7515 (JWS), RFC 7516 (JWE) — IETF. Documentos públicos.
| Parte | Contenido | Codificación |
|---|---|---|
| Header | {"alg": "HS256", "typ": "JWT"} | Base64url |
| Payload | Claims: sub (sujeto), iss (emisor), exp (expiración), iat (emitido), custom claims | Base64url |
| Signature | HMAC-SHA256(base64(header) + "." + base64(payload), secret) | Base64url |
| Formato final |
|---|
header.payload.signature — tres partes separadas por puntos |
Pregunta clave: JWT tiene 3 partes separadas por puntos. El payload NO está cifrado (solo codificado en Base64). Para confidencialidad se usa JWE. Algoritmos comunes:HS256(simétrico),RS256(asimétrico RSA).
OpenAPI / Swagger
| Concepto | Descripción |
|---|---|
| OpenAPI Specification (OAS) | Estándar para describir APIs REST en formato YAML/JSON. Versión actual: 3.1 |
| Swagger | Conjunto de herramientas: Swagger UI (documentación interactiva), Swagger Editor, Swagger Codegen |
| Enfoque Contract-First | Diseñar el OpenAPI spec primero, luego generar código |
| Enfoque Code-First | Escribir código con anotaciones, generar el spec automáticamente |
JAX-RS (API Java para REST)
| Anotación | Función |
|---|---|
@Path("/recurso") | URI base del recurso |
@GET, @POST, @PUT, @DELETE | Verbo HTTP del método |
@Produces("application/json") | Formato de respuesta |
@Consumes("application/json") | Formato aceptado en request |
@PathParam, @QueryParam, @HeaderParam | Extracción de parámetros |
GraphQL
Fuente: GraphQL Specification (spec.graphql.org) — licencia OWFa. Creado por Facebook (2012, open source 2015).
| Operación | Función | Equivalente REST |
|---|---|---|
| Query | Leer datos. El cliente especifica exactamente qué campos quiere | GET |
| Mutation | Modificar datos (crear, actualizar, eliminar) | POST, PUT, DELETE |
| Subscription | Recibir datos en tiempo real (WebSocket) | SSE / WebSocket |
| Ventaja GraphQL | Problema REST que resuelve |
|---|---|
| No over-fetching | REST devuelve todos los campos; GraphQL solo los pedidos |
| No under-fetching | REST puede requerir múltiples requests; GraphQL un solo query anidado |
| Schema tipado | Contrato estricto: types, fields, arguments. Introspección |
| Un solo endpoint | REST tiene múltiples URIs; GraphQL usa POST /graphql |
gRPC (Google Remote Procedure Call)
Fuente: grpc.io — documentación oficial (Apache 2.0). Especificación de Protocol Buffers: protobuf.dev.
| Aspecto | Descripción |
|---|---|
| Protocolo | HTTP/2: multiplexación, compresión de headers, streams |
| Serialización | Protocol Buffers (binario, ~10x más compacto que JSON) |
| Contrato | Archivos .proto que definen servicios y mensajes |
| Generación código | protoc genera stubs en múltiples lenguajes (Java, Go, Python, C#...) |
| Tipos de llamada | Unary (req/res), Server streaming, Client streaming, Bidirectional streaming |
| Caso de uso ideal | Comunicación interna entre microservicios: baja latencia, alto throughput |
| Limitación | Navegadores no soportan HTTP/2 framing directo → se usa gRPC-Web como proxy |
SOA (Service-Oriented Architecture)
Fuente: OASIS SOA Reference Model (docs.oasis-open.org). Modelo arquitectónico, no una tecnología específica.
| Principio SOA | Descripción |
|---|---|
| Contrato estandarizado | Los servicios exponen un contrato formal (WSDL, OpenAPI) |
| Acoplamiento débil | Los servicios minimizan dependencias entre sí |
| Abstracción | Solo se expone el contrato; la implementación interna es opaca |
| Reutilización | Los servicios se diseñan para ser reutilizados por múltiples consumidores |
| Composición | Los servicios se combinan en procesos de negocio (orquestación/coreografía) |
| Autonomía | Cada servicio controla su lógica y recursos |
| Descubrimiento | Los servicios son localizables (registro UDDI, Service Registry) |
ESB (Enterprise Service Bus)
| Función ESB | Descripción |
|---|---|
| Routing | Enrutar mensajes al servicio correcto (content-based routing) |
| Transformación | Convertir formatos: XML ↔ JSON, mapeado de esquemas |
| Mediación | Intermediario entre servicios heterogéneos (protocolo, formato) |
| Orquestación | Coordinar flujos de negocio multi-servicio (BPEL) |
| Monitorización | Logging, métricas, alertas de toda la comunicación |
| Productos | MuleSoft, IBM Integration Bus, Apache ServiceMix, WSO2 ESB |
MICROSERVICIOS vs SOA
| Aspecto | SOA tradicional | Microservicios |
|---|---|---|
| Comunicación | ESB centralizado | Directa (HTTP/REST, gRPC, mensajería) |
| Granularidad | Servicios grandes, reutilizables | Servicios pequeños, una responsabilidad |
| BD | BD compartida (frecuente) | BD por servicio (Database per Service) |
| Deploy | Centralizado | Independiente por servicio (contenedores) |
| Gobernanza | Centralizada | Descentralizada (cada equipo elige su stack) |
| API Gateway | ESB hace de gateway | API Gateway dedicado (Kong, NGINX, AWS API Gateway) |
FUENTES PÚBLICAS
Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
| Fuente | Tipo | Referencia |
|---|---|---|
| W3C SOAP 1.2, WSDL 1.1/2.0 | Estándar | w3.org/TR/soap12, w3.org/TR/wsdl |
| OASIS WS-Security, WS-ReliableMessaging | Estándar | docs.oasis-open.org |
| Roy Fielding (2000) — Tesis REST | Publicación académica | ics.uci.edu/~fielding/pubs/dissertation (pública) |
| RFC 9110 — HTTP Semantics | Estándar | IETF |
| RFC 7519 — JWT | Estándar | IETF |
| RFC 6749 — OAuth 2.0 | Estándar | IETF |
| GraphQL Specification | Especificación | spec.graphql.org (OWFa) |
| gRPC Documentation | Documentación oficial | grpc.io (Apache 2.0) |