Programming & Development

APIs & Microservices

Intermediate 7 modules • 20 hours •59 € VAT included

Curso orientado a diseñar y consumir APIs HTTP con criterio tecnico, y a entender cuando una arquitectura de microservicios aporta valor y cuando solo añade complejidad. El enfoque cubre REST, contratos, versionado, seguridad, resiliencia, mensajeria y observabilidad.

Las APIs conectan aplicaciones, equipos y dominios de negocio. Un diseño pobre genera acoplamientos, integraciones fragiles y problemas de seguridad. Los microservicios, por su parte, no son un fin en si mismos: son una estrategia de particion arquitectonica que exige limites claros, autonomia, operacion distribuida y capacidad de observacion.

The first module is free. Request information about full-course access.

Please note: the course material (modules, exam, glossary and labs) is written in Spanish. Only the site interface is available in English. A good reading level of Spanish is required.

On sale soon. The first module is free: sign up and start.

hola@itlabcert.com

Request received. We will reply to your email within 48 working hours. No need to send it again.

For myself For my company or team

I have read and accept the privacy policy. We will only use your data to reply to you.

hola@itlabcert.com

Modulo 01. HTTP, REST y principios de diseño de APIs

Objetivo del modulo

Comprender HTTP como protocolo base de las APIs web y aplicar principios REST para diseñar recursos, operaciones y respuestas con semantica consistente.

Resultados esperados

Diferenciar metodo HTTP, recurso, endpoint y representacion.
Elegir codigos de estado adecuados.
Diseñar rutas RESTful legibles.
Evitar errores frecuentes de semantica HTTP.

Desarrollo teorico

Toda API HTTP se apoya en el protocolo web. Antes de hablar de frameworks o microservicios hay que entender que una peticion HTTP tiene metodo, URI, cabeceras, cuerpo y semantica de respuesta. GET recupera representaciones, POST crea o desencadena procesamiento, PUT reemplaza, PATCH modifica parcialmente y DELETE elimina. No son simplemente verbos intercambiables; cada uno comunica intencion al cliente, a caches, proxies, herramientas y equipos humanos.

REST no es "usar JSON con HTTP". Es un estilo arquitectonico que enfatiza recursos identificables por URI, operaciones uniformes, ausencia de estado de sesion en el servidor para cada peticion y uso correcto del protocolo subyacente. En diseño cotidiano, esto suele traducirse a modelar bien los recursos: /users, /orders/123, /tickets/ABC-1/comments. Un anti-patron comun es usar rutas basadas en acciones para todo, como /createUser o /deleteServer, desperdiciando la semantica de HTTP.

Los codigos de estado tambien importan. 200 OK indica exito general; 201 Created es adecuado tras crear un recurso; 204 No Content encaja cuando la operacion fue correcta pero no devuelve cuerpo; 400 Bad Request refleja entrada invalida; 401 Unauthorized indica falta de autenticacion valida; 403 Forbidden significa que el cliente esta autenticado pero no tiene permiso; 404 Not Found expresa ausencia del recurso; 409 Conflict es util para colisiones de estado; 500 y familia indican problemas del lado servidor.

Metodo	Uso principal	Idempotencia	Ejemplo
GET	leer recurso	si	obtener ticket
POST	crear o ejecutar operacion	no necesariamente	crear pedido
PUT	reemplazo completo	si	actualizar perfil completo
PATCH	cambio parcial	depende del diseño	cambiar estado
DELETE	eliminar	idealmente si	borrar recurso

Diseñar bien una API significa tambien pensar en paginacion, filtrado, ordenacion y estructura de errores. Si /tickets puede devolver miles de elementos, necesita page, limit, cursores u otro mecanismo. Si la respuesta de error cambia en cada endpoint, el consumidor sufrira. Una API profesional debe ser predecible tanto en el camino feliz como cuando algo sale mal.

Ejemplo practico de API REST

Un diseño RESTful para un sistema de tickets ilustra las decisiones habituales:

# Listar tickets con filtros y paginacion
GET /api/v1/tickets?status=open&priority=high&page=1&limit=20
Accept: application/json
Authorization: Bearer eyJhbGci...

HTTP/1.1 200 OK
Content-Type: application/json

{
  "data": [
    {
      "id": "TK-1042",
      "title": "Error en SSO corporativo",
      "status": "open",
      "priority": "high",
      "assignee": null,
      "createdAt": "2026-03-15T10:30:00Z"
    }
  ],
  "total": 87,
  "page": 1,
  "pageSize": 20
}

# Crear un ticket
POST /api/v1/tickets
Content-Type: application/json
Authorization: Bearer eyJhbGci...

{
  "title": "VPN no conecta desde la oficina de Madrid",
  "description": "Desde esta mañana varios usuarios reportan timeout al conectar la VPN.",
  "priority": "high"
}

HTTP/1.1 201 Created
Location: /api/v1/tickets/TK-1043
Content-Type: application/json

{
  "data": {
    "id": "TK-1043",
    "title": "VPN no conecta desde la oficina de Madrid",
    "status": "open",
    "priority": "high",
    "createdAt": "2026-03-27T09:15:00Z"
  }
}

# Cambiar estado parcialmente
PATCH /api/v1/tickets/TK-1043
Content-Type: application/json

{ "status": "in_progress", "assignedTo": "agent-007" }

HTTP/1.1 200 OK

# Eliminar un ticket
DELETE /api/v1/tickets/TK-1043

HTTP/1.1 204 No Content

Estructura de errores consistente

Una API profesional devuelve errores con formato predecible. El consumidor no deberia adivinar donde esta el mensaje de error:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Datos de entrada invalidos",
    "details": {
      "title": "Debe tener al menos 5 caracteres",
      "priority": "Valor no permitido. Opciones: low, medium, high, critical"
    },
    "requestId": "req-abc123"
  }
}

Paginacion con cursores frente a offset

La paginacion por offset (page=3&limit=20) es simple pero se degrada en tablas grandes. La paginacion por cursor es mas eficiente porque no necesita contar filas anteriores:

# Paginacion por cursor
GET /api/v1/tickets?limit=20&after=TK-1040

{
  "data": [...],
  "pagination": {
    "hasNext": true,
    "nextCursor": "TK-1060"
  }
}

El cursor suele ser el ID o timestamp del ultimo elemento. Es mas resistente a inserciones concurrentes que el offset, porque no se desplazan posiciones cuando se añaden nuevos registros.

Contenido ampliado

Cabeceras comunes como Content-Type, Accept y Authorization.
Idempotencia y seguridad de metodos.
Colecciones, subrecursos y acciones excepcionales.

Puntos clave

HTTP no es solo transporte; aporta semantica.
REST se apoya en recursos coherentes y operaciones uniformes.
Los codigos de estado comunican resultado funcional y tecnico.
Una API buena es predecible y consistente.

Checklist operativa

Verificar que cada ruta modela un recurso real.
Elegir metodo HTTP segun la intencion.
Devolver codigos de estado alineados con el resultado.
Diseñar respuestas de error consistentes.

Errores frecuentes

Usar POST para cualquier operacion.
Diseñar rutas basadas solo en verbos.
Responder 200 incluso cuando hay error funcional.
Ignorar paginacion en colecciones grandes.

Practica sugerida

Diseña una API de tickets con endpoints de listado, detalle, creacion, cambio de estado y comentarios, indicando metodos y codigos de estado esperados.

Preguntas de autoevaluacion

Por que 201 Created no equivale a 200 OK.
Cuando tiene sentido PATCH frente a PUT.
Que problema resuelve modelar recursos y no acciones arbitrarias.

Cierre

Una API madura empieza por respetar el protocolo que la sostiene; por eso HTTP y REST son la base de todo el curso.

Definir contratos estables entre proveedor y consumidor de API y aprender a evolucionarlos sin romper integraciones existentes.

What you will learn

Explicar que es un contrato de API.
Diseñar payloads y esquemas coherentes.
Aplicar estrategias basicas de versionado.
Entender compatibilidad hacia atras.

Module contents

Especificacion OpenAPI
Cambios compatibles frente a breaking changes
Estrategias de versionado
Deprecacion y comunicacion