1. INTRODUCCIÓN: LA WEB COMO SISTEMA DISTRIBUIDO

Internet es una infraestructura mundial de redes interconectadas; la Web es uno de los servicios construidos sobre esa infraestructura. Esta distinción es esencial: Internet aporta direccionamiento, encaminamiento y transporte mediante la familia TCP/IP, mientras que la Web articula recursos identificados por URI, clientes y servidores que intercambian representaciones mediante HTTP. Correo electrónico, transferencia de archivos, resolución DNS o mensajería pueden utilizar Internet sin ser, por ello, la Web. En una pregunta de oposición, equiparar Internet y World Wide Web suele ser una simplificación incorrecta.

Una aplicación web moderna debe entenderse como un sistema distribuido. El navegador interpreta HTML, aplica CSS y ejecuta JavaScript; uno o varios servidores reciben peticiones, aplican reglas de negocio y acceden a datos; componentes intermedios —proxies, balanceadores, pasarelas de API, cachés o redes de distribución de contenidos— modifican el recorrido de la comunicación. La respuesta visible en pantalla es el resultado de una cadena de capas técnicas y organizativas, no únicamente de un documento almacenado en un servidor.

El modelo básico es de petición y respuesta. El cliente resuelve el nombre del servidor, establece el canal de transporte y, cuando procede, negocia TLS. A continuación envía una petición HTTP que identifica un método, un destino y metadatos. El servidor produce una respuesta con un código de estado, campos de cabecera y, normalmente, un cuerpo. El cuerpo puede contener HTML para representación directa, JSON o XML para una API, una imagen, un documento o cualquier otro tipo de medio identificado mediante un tipo MIME.

La arquitectura puede organizarse en dos niveles —cliente y servidor de datos o aplicación—, tres niveles —presentación, lógica y datos— o múltiples niveles. La separación en capas facilita sustituir tecnologías, escalar componentes de forma independiente y aplicar controles de seguridad específicos. También introduce complejidad: fallos parciales, latencia, consistencia de datos, observabilidad y coordinación de despliegues. Por ello, un diseño web profesional no se limita a elegir un lenguaje; debe definir contratos, responsabilidades y mecanismos de recuperación.

En el ámbito sanitario, la disponibilidad y la confidencialidad tienen especial relevancia. Una aplicación clínica puede manejar datos especialmente protegidos, integrar múltiples sistemas y ser utilizada durante procesos asistenciales sensibles al tiempo. El desarrollo web debe incorporar autenticación, autorización, trazabilidad, validación de entradas, cifrado en tránsito, gestión segura de sesiones y pruebas de accesibilidad. No puede confiarse en el navegador como frontera de seguridad: cualquier validación del cliente debe repetirse en el servidor.

Este tema recorre la evolución y las características de HTML, HTTP y XML; diferencia desarrollo en cliente y servidor; estudia JavaScript, AJAX, componentes distribuidos y sistemas de gestión de contenidos; y concluye con la Web semántica. La finalidad no es memorizar marcas comerciales, sino dominar conceptos estables: recursos, representaciones, estado, contratos, interoperabilidad y semántica.

2. ARQUITECTURAS WEB, IDENTIFICACIÓN DE RECURSOS Y CAPAS

La arquitectura web clásica sigue el patrón cliente-servidor. El cliente inicia la comunicación y solicita una operación; el servidor escucha en un punto de acceso, interpreta la petición y devuelve una respuesta. El servidor puede ser, a su vez, cliente de otros servicios. Esta recursividad explica por qué una página aparentemente sencilla puede depender de autenticación corporativa, directorios, servicios clínicos, bases de datos, sistemas de mensajería y proveedores externos.

2.1. URI, URL y recursos

HTTP opera sobre recursos, conceptos identificables que pueden tener diferentes representaciones. Una URI identifica un recurso; una URL, además, expresa un mecanismo y una localización de acceso. En el uso cotidiano ambos términos se solapan, pero el criterio importante es que la dirección no debe confundirse con el contenido. El mismo recurso puede representarse como HTML, JSON o XML según negociación, versión o endpoint.

https://servicios.ejemplo.es/api/pacientes/123?vista=resumen
└─ esquema ─┘ └──── autoridad ────┘└──── ruta ─────┘└─ consulta ─┘

El fragmento introducido por # se procesa normalmente en el cliente y no forma parte de la petición HTTP enviada al servidor. La consulta introducida por ? sí forma parte del objetivo de la petición. Los caracteres especiales deben codificarse según las reglas de URI; no debe aplicarse una codificación indiscriminada a toda la dirección, porque separadores como /, ? o & tienen significado estructural.

2.2. Dos, tres y múltiples capas

La presentación puede renderizarse en el servidor, en el cliente o mediante un enfoque híbrido. En el renderizado del lado servidor, el backend genera HTML para cada navegación. En una aplicación de página única, el servidor entrega una base y el cliente obtiene datos para actualizar la interfaz. Los enfoques híbridos pueden prerenderizar, hidratar componentes y continuar la interacción en el navegador. Ninguno es universalmente superior: la elección depende de accesibilidad, rendimiento, complejidad, indexación, conectividad y capacidad del equipo.

2.3. Intermediarios

HTTP permite intermediarios. Un proxy directo actúa en nombre del cliente; un proxy inverso recibe tráfico en nombre de servidores; una caché reutiliza respuestas cuando las directivas lo permiten; un balanceador distribuye carga; una pasarela aplica autenticación, cuotas, transformación o encaminamiento. Un cortafuegos de aplicaciones web inspecciona patrones de ataque, pero no sustituye a la codificación de salida, la validación y el diseño seguro.

La presencia de intermediarios exige no asumir que la conexión TCP observada por la aplicación corresponde directamente al usuario final. Cabeceras de reenvío deben aceptarse solo desde intermediarios confiables. También obliga a diseñar identificadores de correlación y trazas distribuidas que permitan seguir una operación a través de varios servicios.

2.4. Estado y sesiones

HTTP se define como protocolo sin estado: cada petición puede comprenderse conforme a su contenido y al estado compartido del recurso, sin requerir que el protocolo recuerde una conversación previa. Las aplicaciones sí pueden mantener estado mediante cookies de sesión, tokens, almacenamiento servidor o parámetros. Decir que HTTP es sin estado no significa que una aplicación web no pueda tener sesión; significa que esa sesión es una construcción por encima del protocolo.

En sistemas de alta disponibilidad, guardar toda la sesión en memoria local de un único nodo obliga a fijar al usuario a ese nodo o a replicar el estado. Alternativas habituales son sesiones compartidas, tokens autocontenidos con límites estrictos o arquitecturas que minimizan el estado conversacional. La decisión debe ponderar revocación, tamaño, privacidad, escalabilidad y consistencia.

3. HTML: EVOLUCIÓN, MODELO Y ESTÁNDAR VIVO

HTML es el lenguaje de marcado fundamental de la Web. Su función es expresar la estructura y el significado del contenido, no programar algoritmos ni definir por sí solo la apariencia visual. Los navegadores construyen a partir del código fuente un árbol de objetos —el DOM— que puede ser consultado y modificado. CSS y JavaScript se integran con ese árbol, pero son tecnologías distintas.

3.1. Evolución histórica

Las primeras propuestas de HTML aparecieron al comienzo de la Web. HTML 2.0 fue normalizado en 1995 mediante RFC 1866; HTML 3.2 se publicó como Recomendación W3C en 1997; HTML 4.0 y HTML 4.01 consolidaron separación de presentación y estructura; XHTML 1.0 reformuló HTML 4.01 utilizando sintaxis XML. HTML5 introdujo un modelo de procesamiento interoperable, elementos semánticos, multimedia nativa, formularios enriquecidos y numerosas APIs asociadas al entorno web.

Tras las recomendaciones numeradas HTML5, HTML 5.1 y HTML 5.2, el mantenimiento efectivo se centra en el HTML Living Standard de WHATWG. Por ello, en la actualidad no resulta preciso presentar “HTML5” como una versión cerrada que será sustituida necesariamente por “HTML6”. HTML evoluciona de forma continua; las características alcanzan distintos grados de implementación y deben evaluarse mediante especificación, compatibilidad y mejora progresiva.

3.2. Documento, sintaxis y procesamiento

Un documento HTML típico declara <!doctype html>, establece el idioma, incluye metadatos en head y contenido en body. El doctype moderno no enlaza una DTD; activa el modo de estándares del navegador. Esta diferencia respecto a HTML 4 o XHTML es una pregunta frecuente: en HTML moderno la declaración es corta y su finalidad práctica es evitar modos de compatibilidad heredados.

<!doctype html>
<html lang="es">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Portal de ejemplo</title>
  </head>
  <body>
    <main>
      <h1>Contenido principal</h1>
    </main>
  </body>
</html>

La sintaxis HTML es tolerante a determinados errores y el estándar define cómo recuperarlos. Esa tolerancia no autoriza a escribir código defectuoso: diferentes errores pueden producir árboles DOM inesperados, dificultar accesibilidad o abrir riesgos cuando se inserta contenido dinámico. La validación ayuda a detectar anidamientos incorrectos, identificadores duplicados, atributos inválidos y otras desviaciones.

HTML puede serializarse con sintaxis HTML y, en determinados contextos, con sintaxis XML. Servir un documento como text/html activa el analizador HTML; servirlo con un tipo XML aplica reglas XML y un error de formación puede impedir la representación. La extensión de archivo no determina por sí sola el modo de procesamiento: el tipo de medio y el contexto son decisivos.

3.3. Semántica y accesibilidad

Elementos como header, nav, main, article, section, aside y footer expresan roles estructurales. La semántica facilita navegación con tecnologías asistivas, mantenimiento, extracción de contenido y comprensión por agentes automáticos. No deben elegirse por su aspecto visual: un section no es un contenedor genérico para aplicar estilos, y un article representa contenido autónomo o reutilizable.

La semántica nativa debe preferirse a recrear controles mediante elementos genéricos y JavaScript. Un botón real aporta activación por teclado, foco y rol accesible; un div con un manejador de clic requiere reproducir correctamente ese comportamiento. ARIA puede completar semántica cuando no existe un elemento apropiado, pero no repara automáticamente una estructura deficiente.

4. HTML MODERNO: CONTENIDO, FORMULARIOS, MULTIMEDIA Y APIS

4.1. Categorías de contenido y estructura

HTML define categorías de contenido —como flujo, fraseado, interactivo o seccionado— y modelos de contenido que determinan qué elementos pueden anidarse. Estas reglas evitan árboles ambiguos. Los encabezados h1 a h6 establecen jerarquía; las listas representan secuencias o conjuntos; las tablas se reservan para datos tabulares y no para maquetación. La estructura visual debe resolverse con CSS.

El elemento main identifica el contenido principal del documento. Debe existir, en la práctica, un único contenido principal expuesto; elementos main alternativos pueden estar ocultos bajo condiciones específicas, pero no debe presentarse al usuario más de uno simultáneamente. header y footer pueden aparecer en la página y dentro de secciones, porque representan cabecera o pie de su ámbito, no únicamente del documento completo.

4.2. Formularios y validación

Los formularios permiten recopilar datos y enviarlos al servidor. label asocia texto con un control; fieldset y legend agrupan opciones; atributos como required, min, max, pattern o tipos especializados aportan validación y experiencia de uso. Los nombres de los controles determinan las claves enviadas.

<form method="post" action="/solicitudes">
  <label for="correo">Correo de contacto</label>
  <input id="correo" name="correo" type="email" required autocomplete="email">
  <button type="submit">Enviar</button>
</form>

La validación del navegador es una ayuda de usabilidad, no una garantía de seguridad. Un atacante puede construir una petición sin usar el formulario, modificar JavaScript o invocar directamente la API. El servidor debe validar formato, rango, autorización y coherencia de negocio. Además, la codificación de salida debe ajustarse al contexto para evitar inyección HTML o JavaScript.

4.3. Imágenes y multimedia

HTML integra audio y vídeo mediante audio, video, source y track. El navegador puede seleccionar formatos compatibles y mostrar subtítulos o descripciones. La reproducción automática está limitada por políticas del navegador y por razones de accesibilidad. Deben proporcionarse controles y alternativas, y no depender de un único formato sin evaluar compatibilidad.

Las imágenes responsivas pueden expresarse con srcset, sizes y picture. El atributo alt comunica la alternativa textual: debe describir la función o información de la imagen, no repetir mecánicamente “imagen de”. En una imagen decorativa, un alt vacío permite que la tecnología asistiva la ignore.

4.4. Canvas, SVG y gráficos

canvas proporciona una superficie de dibujo controlada por script y resulta útil para gráficos dinámicos, pero su contenido no conserva por defecto una estructura semántica equivalente a los objetos dibujados. SVG representa gráficos vectoriales como árbol de elementos, facilitando estilos, interacción y accesibilidad. La elección depende de volumen de objetos, necesidad de manipulación, rendimiento y requisitos de acceso alternativo.

4.5. APIs relacionadas con el entorno HTML

El ecosistema del navegador incluye almacenamiento web, historial, geolocalización, trabajadores, mensajería, WebSocket y otras APIs. No todas pertenecen estrictamente al núcleo de HTML ni todas requieren el mismo permiso. En examen conviene distinguir el lenguaje de marcado de las APIs disponibles en el agente de usuario. JavaScript accede a ellas mediante objetos definidos por especificaciones del entorno.

localStorage conserva pares clave-valor por origen y tiene interfaz síncrona; sessionStorage se limita a la sesión de una pestaña; IndexedDB es una base de datos asíncrona para datos estructurados. Ninguno debe usarse para guardar secretos permanentes accesibles a JavaScript. Un ataque XSS puede leer el almacenamiento disponible para el origen.

Los service workers actúan como intermediarios programables entre aplicación, red y caché. Permiten estrategias sin conexión, actualización y notificaciones bajo condiciones. Exigen contexto seguro salvo excepciones de desarrollo y tienen ciclo de vida independiente de la página. No deben confundirse con web workers, cuyo objetivo principal es ejecutar tareas fuera del hilo de interfaz.

5. HTTP: SEMÁNTICA, MENSAJES, MÉTODOS Y ESTADO

HTTP es una familia de protocolos de aplicación, sin estado y basada en mensajes de petición y respuesta. La semántica común está definida por RFC 9110 y puede transportarse mediante HTTP/1.1, HTTP/2 o HTTP/3. Esta separación evita atribuir a una versión concreta conceptos que pertenecen a todas: métodos, códigos de estado, campos y representación de recursos.

5.1. Peticiones y respuestas

Una petición incluye método, objetivo y campos; una respuesta incluye código de estado y campos. En HTTP/1.1 existe una representación textual con línea inicial y cabeceras; HTTP/2 y HTTP/3 utilizan tramas binarias y pseudocabeceras, pero conservan la semántica. No debe afirmarse que HTTP/2 “cifra los mensajes” por ser binario: el formato binario no equivale a cifrado. En navegadores, HTTP/2 se despliega habitualmente sobre TLS, pero son conceptos diferentes.

GET /api/citas?paciente=123 HTTP/1.1
Host: servicios.ejemplo.es
Accept: application/json
Authorization: Bearer <token>

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"citas":[]}

5.2. Métodos, seguridad e idempotencia

Un método seguro pretende no solicitar cambio de estado en el servidor, aunque puedan producirse registros, métricas o efectos incidentales. Idempotencia significa que múltiples peticiones idénticas tienen el mismo efecto pretendido que una sola, no que las respuestas deban ser idénticas. Por ejemplo, repetir DELETE puede devolver primero 204 y después 404, pero el efecto final sigue siendo que la asociación no existe.

5.3. Códigos de estado

Los códigos 1xx son informativos; 2xx indican tratamiento satisfactorio; 3xx redirección o uso de otra representación; 4xx señalan que la petición no puede satisfacerse por condiciones atribuibles al lado cliente; 5xx expresan fallo del servidor al procesar una petición aparentemente válida. El texto descriptivo no determina el significado; lo hace el código.

• 200 OK: resultado satisfactorio genérico.
• 201 Created: se ha creado uno o más recursos; suele acompañarse de Location.
• 204 No Content: éxito sin cuerpo de respuesta.
• 301 Moved Permanently y 308 Permanent Redirect: redirección permanente; 308 preserva método y cuerpo.
• 304 Not Modified: validación de caché; no es una respuesta de redirección hacia otra URL.
• 400 Bad Request: petición inválida o no procesable a nivel de sintaxis/protocolo.
• 401 Unauthorized: faltan credenciales válidas; el nombre histórico puede inducir a confusión.
• 403 Forbidden: el servidor entiende la petición pero rechaza autorizarla.
• 404 Not Found: el recurso no se encuentra o el servidor no desea revelar su existencia.
• 409 Conflict: conflicto con el estado actual del recurso.
• 429 Too Many Requests: se ha superado un límite de frecuencia.
• 500 Internal Server Error y 503 Service Unavailable: fallo genérico o indisponibilidad temporal.

5.4. Campos y representaciones

Content-Type describe el tipo del contenido enviado; Accept expresa tipos aceptables; Content-Encoding indica transformaciones como compresión; Authorization transporta credenciales; Location identifica otro recurso; ETag ofrece un validador. Confundir Content-Type con Accept es frecuente: el primero describe lo que viaja en ese mensaje, el segundo negocia lo que el receptor desea.

Los campos son extensibles y no deben tratarse como sensibles a mayúsculas en su nombre. Su uso debe respetar reglas de combinación y seguridad. Copiar cabeceras aportadas por el cliente a una respuesta sin filtrado puede permitir inyección; confiar en cabeceras de IP o protocolo sin controlar el proxy puede facilitar suplantación.

6. EVOLUCIÓN DE HTTP: 0.9, 1.0, 1.1, 2 Y 3

6.1. De HTTP/0.9 a HTTP/1.1

HTTP/0.9 fue un protocolo mínimo para obtener documentos. HTTP/1.0 incorporó códigos de estado, cabeceras y tipos de contenido, pero cada intercambio se asociaba normalmente a una conexión. HTTP/1.1 generalizó conexiones persistentes, exigió el campo Host, añadió transferencia por fragmentos, mecanismos de caché y un conjunto consolidado de métodos. La posibilidad de alojar varios sitios en una IP depende en gran medida de que el cliente identifique el host solicitado.

HTTP/1.1 permitió pipelining, pero su uso fue limitado por complejidad e interferencias. Aunque varias peticiones pudieran enviarse sin esperar respuestas, estas debían conservar orden, de modo que una respuesta lenta bloqueaba las posteriores en la conexión. Los navegadores mitigaron el problema abriendo varias conexiones, con coste adicional.

6.2. HTTP/2

HTTP/2, definido actualmente por RFC 9113, conserva métodos, códigos y URI, pero cambia la forma de transporte. Divide mensajes en tramas binarias, multiplexa varios flujos dentro de una conexión, comprime campos con HPACK y permite priorización. La multiplexación evita el bloqueo de nivel de aplicación propio del orden de respuestas de HTTP/1.1, aunque todos los flujos siguen compartiendo una conexión TCP.

Cuando TCP pierde un segmento, la entrega ordenada detiene temporalmente los datos posteriores de la conexión, incluso si pertenecen a otros flujos HTTP/2. Este bloqueo de cabecera de línea en transporte es una motivación para HTTP/3. No debe afirmarse que HTTP/2 elimina toda forma de head-of-line blocking; elimina la asociada al protocolo HTTP/1.1, no la inherente a TCP.

6.3. HTTP/3 y QUIC

HTTP/3, definido por RFC 9114, mapea la semántica HTTP sobre QUIC. QUIC se ejecuta sobre UDP, pero implementa transporte seguro, control de congestión, entrega fiable por flujo y negociación integrada con TLS 1.3. Por tanto, la formulación rigurosa no es “HTTP/3 utiliza UDP y deja de ser fiable”, sino “HTTP/3 utiliza QUIC, que construye transporte fiable y cifrado sobre datagramas UDP”.

Cada flujo QUIC mantiene su orden independiente. La pérdida de datos en un flujo no bloquea necesariamente los demás, aunque la congestión y la red sigan siendo compartidas. QUIC utiliza identificadores de conexión que facilitan continuidad cuando cambia la dirección de red, bajo controles de seguridad. QPACK comprime campos en HTTP/3 y está diseñado para reducir bloqueos derivados de dependencias de compresión.

QUIC integra TLS 1.3. La reanudación puede permitir datos tempranos 0-RTT, pero estos datos tienen riesgo de repetición y solo deben usarse para operaciones seguras frente a replay. No es correcto presentar 0-RTT como “conexión instantánea sin handshake” en todos los casos: depende de una relación previa, de la configuración y de la naturaleza de la petición.

6.4. HTTPS y TLS

HTTPS es HTTP comunicado sobre un canal TLS. TLS aporta confidencialidad, integridad y autenticación del servidor mediante certificados; opcionalmente puede autenticar al cliente. SSL es el antecedente histórico y está obsoleto: en documentación moderna debe hablarse de TLS. El puerto convencional de HTTPS es 443, aunque el esquema y el puerto no son inseparables.

Un candado del navegador indica que el canal se ha establecido con un certificado aceptado para el nombre y la cadena de confianza, pero no garantiza que el sitio sea legítimo en sentido comercial ni que su contenido sea seguro. Un atacante también puede obtener un certificado para un dominio que controla. La seguridad exige verificar destino, autorización y comportamiento de la aplicación.

7. CACHÉ, NEGOCIACIÓN, COOKIES, CORS Y SEGURIDAD HTTP

7.1. Caché y validación condicional

La caché HTTP reduce latencia, ancho de banda y carga del servidor. Una respuesta puede ser almacenada por el navegador, por una caché compartida o por una red de distribución, según método, código y directivas. Cache-Control expresa políticas como max-age, no-cache, no-store, private o public. no-cache no significa “no almacenar”: obliga a revalidar antes de reutilizar. no-store solicita que no se almacene.

Los validadores permiten comprobar si una representación ha cambiado. ETag es un identificador opaco asignado por el servidor; Last-Modified comunica una fecha. El cliente puede enviar If-None-Match o If-Modified-Since. Si la representación sigue vigente, el servidor responde 304 sin transferir de nuevo el cuerpo. Para concurrencia optimista pueden emplearse condiciones como If-Match, evitando sobrescribir una versión que cambió desde la lectura.

GET /documentos/42 HTTP/1.1
If-None-Match: "v7"

HTTP/1.1 304 Not Modified
ETag: "v7"

En información sensible, una política de caché incorrecta puede exponer datos en equipos compartidos o intermediarios. Cache-Control: no-store es apropiado para determinadas respuestas confidenciales, pero la decisión debe tomarse por tipo de dato y flujo. La seguridad no se resuelve únicamente con una cabecera: también importan cierre de sesión, almacenamiento local, historial y controles del puesto.

7.2. Negociación de contenido

Un recurso puede ofrecer varias representaciones. El cliente expresa preferencias mediante Accept, Accept-Language o Accept-Encoding; el servidor selecciona una y puede incluir Vary para que las cachés distingan variantes. La negociación permite entregar JSON o XML desde un mismo concepto de recurso, pero también aumenta combinaciones de prueba y riesgo de caché incorrecta.

Los tipos de medio son parte del contrato. application/json, application/xml, text/html o tipos especializados comunican cómo interpretar el cuerpo. No basta con que el texto “parezca JSON”: el tipo, el juego de caracteres y el esquema esperado deben ser coherentes. El cliente no debe ejecutar o insertar contenido basándose solo en la extensión de la URL.

7.3. Cookies

Una cookie es un pequeño dato asociado a un dominio y ruta que el navegador puede reenviar en peticiones. El servidor la establece con Set-Cookie. Atributos esenciales son Secure, que limita el envío a canales seguros; HttpOnly, que impide acceso mediante las APIs habituales de JavaScript; y SameSite, que restringe envío en contextos entre sitios y ayuda frente a CSRF. Expires o Max-Age controlan persistencia.

HttpOnly reduce el robo directo de la cookie mediante XSS, pero no evita que un script malicioso ejecute acciones en nombre del usuario. SameSite es una defensa relevante, no universal. Los tokens anti-CSRF, la comprobación de origen y el diseño de métodos siguen siendo necesarios según el escenario. Las cookies no son el único mecanismo de sesión, pero están integradas con el navegador y tienen propiedades que deben configurarse explícitamente.

7.4. Política del mismo origen y CORS

La política del mismo origen restringe cómo un documento o script de un origen accede a recursos de otro. Un origen se define por esquema, host y puerto. Dos direcciones con diferente subdominio, protocolo o puerto son orígenes distintos. La política protege datos del usuario frente a scripts de sitios ajenos.

CORS es un mecanismo de cabeceras HTTP mediante el que un servidor autoriza ciertos accesos entre orígenes. El navegador puede realizar una petición preliminar preflight con OPTIONS cuando el método, las cabeceras o el tipo de contenido no encajan en las peticiones simples. El servidor responde con campos como Access-Control-Allow-Origin, Access-Control-Allow-Methods y Access-Control-Allow-Headers.

Combinar credenciales con un origen comodín es incompatible con el modelo de CORS. Reflejar cualquier valor de Origin sin validación abre el acceso a sitios no confiables. La lista de orígenes permitidos debe ser explícita y mantenerse como configuración de seguridad.

7.5. Cabeceras defensivas

La Política de Seguridad de Contenidos —CSP— limita fuentes de scripts, estilos, imágenes y otros recursos, reduciendo impacto de inyección. Strict-Transport-Security indica al navegador que use HTTPS durante un periodo; X-Content-Type-Options: nosniff evita ciertas inferencias de tipo; políticas de referencia y permisos controlan exposición de URL y APIs. Estas cabeceras complementan, pero no sustituyen, el desarrollo seguro.

Una CSP estricta suele requerir eliminar scripts en línea o autorizarlos mediante nonces o hashes. Implementarla sin inventario puede romper funcionalidad. Es recomendable desplegar primero una política de informe, analizar violaciones y endurecer gradualmente. En aplicaciones corporativas, la configuración debe versionarse y probarse igual que el código.

8. XML: ESTRUCTURA, VALIDEZ, ESPACIOS DE NOMBRES Y TECNOLOGÍAS ASOCIADAS

XML es un metalenguaje de marcado diseñado para representar información estructurada mediante elementos, atributos y texto. A diferencia de HTML, no define un vocabulario de presentación preestablecido: cada dominio crea nombres y reglas. La finalidad principal es transportar o almacenar datos con estructura explícita, interoperable y extensible.

8.1. Documento bien formado

Un XML bien formado cumple las reglas sintácticas de XML: un único elemento raíz, etiquetas correctamente anidadas, nombres válidos, atributos entre comillas y caracteres reservados escapados. XML distingue mayúsculas y minúsculas. <Paciente> y <paciente> son nombres diferentes. Los elementos vacíos pueden escribirse con etiqueta de apertura y cierre o como <elemento/>.

<?xml version="1.0" encoding="UTF-8"?>
<paciente id="123">
  <nombre>Ana García</nombre>
  <activo>true</activo>
</paciente>

La declaración XML es opcional en determinados contextos, pero cuando aparece debe situarse al inicio. La codificación real debe coincidir con la declarada. XML 1.0, Quinta Edición, continúa siendo una referencia estable; XML 1.1 existe, aunque XML 1.0 domina el intercambio general. La quinta edición de XML 1.0 incorpora erratas y no constituye una “versión 1.5”.

8.2. Documento válido

La validez añade conformidad con una gramática o esquema. Un documento puede estar bien formado y no ser válido. La DTD define elementos, atributos y entidades mediante una sintaxis propia; XSD utiliza XML y aporta tipos de datos, espacios de nombres, restricciones y composición más rica. También existen otros lenguajes de esquema, como RELAX NG o Schematron, con objetivos diferentes.

XSD 1.1 es Recomendación W3C y añade, entre otras capacidades, aserciones, pero su soporte no es uniforme en todas las herramientas. En un proyecto debe seleccionarse una versión compatible con productores, consumidores, validadores y bibliotecas. El hecho de que una versión sea más reciente no garantiza que sea la elección interoperable.

8.3. Espacios de nombres

Los espacios de nombres evitan colisiones entre vocabularios. Un URI identifica el espacio; un prefijo es solo una abreviatura local. Dos prefijos distintos pueden referirse al mismo espacio y tener idéntico significado. El URI no tiene que ser una página descargable. Los atributos sin prefijo no heredan automáticamente el espacio de nombres predeterminado, un matiz relevante en validación.

<doc:informe
  xmlns:doc="urn:ejemplo:documento"
  xmlns:sec="urn:ejemplo:seguridad">
  <doc:titulo>Resultado</doc:titulo>
  <sec:firma algoritmo="..." />
</doc:informe>

8.4. XPath, XSLT y XQuery

XPath selecciona nodos y calcula valores sobre un modelo XML. XSLT transforma árboles XML en XML, HTML, texto u otras salidas. XQuery consulta y construye información a partir de fuentes XML. Estas tecnologías comparten modelos y funciones en sus ediciones modernas, pero no deben confundirse: XPath es lenguaje de expresiones y rutas; XSLT es lenguaje de transformación; XQuery se orienta a consulta.

/pacientes/paciente[@activo='true']/nombre

La evaluación de expresiones debe considerar espacios de nombres. Una ruta que utiliza nombres sin prefijo no seleccionará necesariamente elementos pertenecientes a un espacio predeterminado. Los procesadores suelen requerir enlazar prefijos en el contexto de consulta.

8.5. SOAP, WSDL y firma XML

SOAP define un sobre XML con cabecera y cuerpo para intercambio de mensajes. Puede transportarse sobre HTTP y otros mecanismos. WSDL describe contratos de servicios: operaciones, mensajes, tipos y puntos de acceso. Las familias WS-* añaden seguridad, direccionamiento, transacciones y otras capacidades. REST y SOAP no son versiones sucesivas del mismo protocolo: responden a estilos y ecosistemas distintos.

8.6. Seguridad XML

Los analizadores XML deben configurarse de forma segura. La expansión de entidades externas puede provocar lectura de archivos, peticiones internas o denegación de servicio —XXE—. La expansión recursiva de entidades puede agotar memoria. Deben deshabilitarse DTD o entidades externas cuando no sean necesarias, limitar tamaños y profundidad, validar contra esquemas controlados y evitar construir consultas XPath concatenando datos no confiables.

9. DESARROLLO DE APLICACIONES WEB EN EL CLIENTE

El desarrollo en cliente comprende el código que ejecuta el agente de usuario. Su objetivo es presentar información, gestionar interacción y comunicarse con servicios. El navegador es una plataforma con motor HTML, CSS, JavaScript, red, almacenamiento y seguridad. No es un entorno confiable desde el punto de vista del servidor: el usuario controla su dispositivo y puede modificar peticiones.

9.1. Carga y representación

Al recibir HTML, el navegador analiza el documento y construye el DOM. CSS se transforma en un modelo de estilos; ambos se combinan para calcular la representación. Cambios en estilos o DOM pueden provocar recalculo, diseño y pintura. El rendimiento no depende solo del tamaño del JavaScript: solicitudes bloqueantes, imágenes, fuentes, complejidad CSS y manipulaciones repetidas influyen en el tiempo de respuesta.

Los scripts clásicos sin atributos pueden bloquear el análisis mientras se descargan y ejecutan. defer permite descargar en paralelo y ejecutar tras el análisis, respetando orden. async ejecuta cuando el recurso está disponible y no garantiza orden entre scripts. Los módulos JavaScript tienen semántica propia, ámbito de módulo y comportamiento diferido por defecto.

9.2. DOM y eventos

El DOM representa documentos mediante nodos. APIs como querySelector, createElement, append o addEventListener permiten manipularlo. Los eventos recorren fases de captura, objetivo y burbujeo. La delegación registra un manejador en un antecesor y utiliza la propagación para atender elementos dinámicos, reduciendo listeners.

document.querySelector("#resultados").addEventListener("click", (evento) => {
  const boton = evento.target.closest("button[data-id]");
  if (!boton) return;
  abrirDetalle(boton.dataset.id);
});

Insertar datos no confiables con innerHTML puede producir XSS. Cuando se desea texto debe usarse textContent. Si se necesita HTML enriquecido, se requiere sanitización mantenida y una política clara de contenido. El escape correcto depende del contexto: texto HTML, atributo, URL, CSS y JavaScript no comparten las mismas reglas.

9.3. Estado en el cliente

La interfaz mantiene estado temporal: selección, filtros, formularios o caché de consultas. Las SPA suelen utilizar gestores de estado o mecanismos reactivos, pero un diseño excesivo aumenta acoplamiento. La URL debe reflejar navegaciones significativas para permitir historial, enlaces y recuperación. La API History modifica la URL sin recarga, pero el servidor debe estar configurado para resolver rutas al cargar directamente.

El almacenamiento local no debe usarse como fuente autoritativa de permisos. El cliente puede ocultar botones según roles para mejorar experiencia, pero el servidor debe comprobar cada operación. Tampoco debe confiarse en precios, identificadores de paciente o flags enviados por la interfaz sin validar su relación con el usuario autenticado.

9.4. Aplicaciones SPA, MPA e híbridas

Una MPA navega entre documentos generados por el servidor. Una SPA carga una aplicación que actualiza vistas mediante JavaScript y APIs. Una arquitectura híbrida combina renderizado servidor, generación estática, componentes interactivos e hidratación. Las SPA pueden ofrecer interacción fluida, pero plantean retos de carga inicial, accesibilidad, gestión de foco, recuperación de errores y complejidad de estado.

9.5. WebSocket, Server-Sent Events y tiempo real

WebSocket establece un canal bidireccional persistente tras una negociación inicial. Server-Sent Events mantiene un flujo unidireccional servidor-cliente sobre HTTP. El sondeo periódico es más simple, aunque menos eficiente. La elección depende de dirección de mensajes, frecuencia, infraestructura intermedia, reintentos y escalabilidad.

Las conexiones persistentes necesitan autenticación, control de origen, límites de mensajes, latidos, reintentos con retroceso y cierre limpio. No deben enviarse datos sensibles a todos los clientes conectados a un canal común. La autorización se aplica también a suscripciones y mensajes, no solo al establecimiento inicial.

10. JAVASCRIPT Y ECMASCRIPT: FUNDAMENTOS PARA LA WEB

JavaScript es el nombre de uso común del lenguaje implementado en navegadores y otros entornos; ECMAScript es la especificación normalizada por Ecma International. En 2026 existe una edición anual ECMAScript 2026, mientras que el borrador de trabajo incorpora cambios de forma continua. El lenguaje no incluye por sí mismo el DOM, fetch o almacenamiento: esas APIs pertenecen al entorno anfitrión.

10.1. Tipos y coerción

Los valores primitivos incluyen undefined, null, booleanos, números, bigint, cadenas y símbolos. Los objetos agrupan propiedades y comportamiento. JavaScript realiza conversiones implícitas en ciertos operadores, lo que explica diferencias entre igualdad abstracta == e igualdad estricta ===. Como norma de claridad suele preferirse ===, aunque es necesario comprender la coerción para interpretar código y APIs.

typeof null devuelve históricamente "object"; NaN es un valor numérico especial y no es igual a sí mismo; Number.isNaN permite comprobarlo sin coerción. Los números ordinarios usan doble precisión, por lo que determinadas fracciones decimales no se representan exactamente. Los cálculos monetarios o clínicos sensibles requieren estrategias de precisión, redondeo y validación explícitas.

10.2. Variables, ámbito y cierres

let y const tienen ámbito de bloque; var tiene ámbito de función y reglas de elevación distintas. const impide reasignar la referencia, no hace inmutable el objeto. Un cierre permite que una función conserve acceso a su entorno léxico, base de callbacks, módulos y encapsulación.

function crearContador() {
  let valor = 0;
  return () => ++valor;
}
const siguiente = crearContador();

Los cierres pueden mantener referencias más tiempo del necesario. Manejadores no eliminados, temporizadores y cachés sin límites provocan fugas de memoria. En aplicaciones de larga vida debe revisarse el ciclo de vida de componentes y suscripciones.

10.3. Objetos, prototipos y clases

JavaScript utiliza herencia prototípica. La sintaxis class ofrece una capa más declarativa, pero no reemplaza el modelo de prototipos. Las propiedades pueden accederse con punto o corchetes. El acceso encadenado debe corresponder a propiedades existentes; el encadenamiento opcional ?. evita errores cuando una referencia es nula o indefinida, pero no corrige un modelo de datos equivocado.

10.4. Asincronía, promesas y tareas

El hilo principal ejecuta una pila de llamadas y coordina colas de tareas. Las promesas representan resultados futuros. async/await ofrece sintaxis secuencial sobre promesas, pero no convierte operaciones en síncronas ni crea automáticamente un hilo. Las continuaciones de promesas se procesan como microtareas antes de la siguiente tarea ordinaria, un detalle que puede afectar al orden observable.

async function cargarCitas(id) {
  const respuesta = await fetch(`/api/citas?paciente=${encodeURIComponent(id)}`);
  if (!respuesta.ok) {
    throw new Error(`HTTP ${respuesta.status}`);
  }
  return respuesta.json();
}

fetch solo rechaza la promesa ante errores de red o situaciones equivalentes; una respuesta 404 o 500 se resuelve normalmente y debe comprobarse mediante ok o status. También deben gestionarse cancelación con AbortController, tiempos máximos de aplicación y estados de carga.

10.5. Módulos

Los módulos ECMAScript utilizan import y export, tienen ámbito propio y se ejecutan en modo estricto. Permiten dependencias explícitas y análisis estático. Los empaquetadores pueden dividir código, eliminar exportaciones no usadas y generar recursos optimizados, pero añaden una cadena de suministro que debe actualizarse y auditarse.

La dependencia de paquetes de terceros introduce riesgo de vulnerabilidades y compromiso. Deben fijarse versiones conforme a una política, revisar archivos de bloqueo, minimizar dependencias, verificar procedencia y automatizar análisis. Una biblioteca de interfaz no autoriza a trasladar al cliente reglas de seguridad.

11. AJAX, FETCH Y COMUNICACIÓN ASÍNCRONA

AJAX significa Asynchronous JavaScript and XML, pero el término describe un patrón, no una obligación de usar XML. Consiste en realizar comunicaciones desde una página ya cargada y actualizar parte de la interfaz sin navegación completa. El formato puede ser JSON, XML, texto, HTML o binario. La asincronía evita bloquear la interacción mientras llega la respuesta, aunque el código debe gestionar concurrencia y errores.

11.1. XMLHttpRequest

XMLHttpRequest fue la API que popularizó AJAX. Permite configurar método, URL, cabeceras, eventos de progreso y tipo de respuesta. Su modelo de eventos es potente, especialmente para progreso de subida, pero produce código más verboso que las promesas. Continúa presente por compatibilidad y por capacidades concretas.

const xhr = new XMLHttpRequest();
xhr.open("GET", "/api/estado");
xhr.responseType = "json";
xhr.addEventListener("load", () => {
  if (xhr.status >= 200 && xhr.status < 300) {
    console.log(xhr.response);
  }
});
xhr.send();

11.2. Fetch API

fetch devuelve una promesa con un objeto Response. Integra objetos Request, Headers y flujos. El cuerpo solo puede consumirse una vez salvo clonación o tratamiento específico. La conversión con json() también es asíncrona. No incorpora un timeout universal como parámetro simple; se puede cancelar mediante AbortSignal.

const controlador = new AbortController();
const temporizador = setTimeout(() => controlador.abort(), 8000);

try {
  const respuesta = await fetch("/api/estado", {
    headers: { "Accept": "application/json" },
    signal: controlador.signal
  });
  if (!respuesta.ok) throw new Error(`HTTP ${respuesta.status}`);
  const datos = await respuesta.json();
  actualizarVista(datos);
} finally {
  clearTimeout(temporizador);
}

11.3. Flujo de una interacción AJAX

Una operación puede fallar a varios niveles: red, TLS, HTTP, parseo, validación o negocio. Devolver 200 con un texto “error” impide que clientes e intermediarios utilicen correctamente la semántica HTTP. La API debe usar códigos, tipos y cuerpos de error consistentes. El cliente debe mostrar mensajes comprensibles sin revelar trazas internas.

11.4. Concurrencia y experiencia de usuario

Si el usuario cambia rápidamente un filtro, varias peticiones pueden completarse fuera de orden. Debe cancelarse la anterior, asociar un identificador o ignorar respuestas obsoletas. Los botones de envío necesitan prevención de duplicados, pero el servidor también debe diseñar idempotencia o claves de operación cuando una repetición pueda crear registros.

Las actualizaciones dinámicas deben comunicar cambios a tecnologías asistivas y gestionar el foco. Un contenido que aparece visualmente puede pasar inadvertido para un lector de pantalla. Regiones vivas, mensajes de estado y patrones de interacción accesibles deben aplicarse con moderación y probarse.

11.5. Seguridad

Los datos obtenidos por AJAX son no confiables aunque procedan del propio servidor: podrían estar manipulados en origen o contener texto introducido por usuarios. Deben insertarse como texto salvo que exista necesidad de HTML y sanitización. Los tokens no deben exponerse en URL, registros o mensajes. Las credenciales y políticas CORS se configuran de acuerdo con el modelo de sesión.

12. DESARROLLO WEB EN EL SERVIDOR

El servidor recibe entradas controladas por clientes, ejecuta reglas de negocio, coordina persistencia e integraciones y produce respuestas. Puede generar HTML, exponer APIs o ambas cosas. Lenguajes como Java, C#, Python, PHP, JavaScript/Node.js, Go o Rust ofrecen ecosistemas distintos, pero la arquitectura debe evaluarse por mantenibilidad, rendimiento, soporte, seguridad, competencias y compatibilidad corporativa.

12.1. Cadena de procesamiento

El servidor web puede servir recursos estáticos y delegar solicitudes dinámicas a un proceso de aplicación. Un servidor de aplicaciones aporta ciclo de vida, agrupación de conexiones, transacciones, seguridad, mensajería y administración. En plataformas modernas estas responsabilidades también se distribuyen entre framework, contenedor, plataforma y servicios gestionados.

12.2. Enrutamiento y controladores

El enrutador asocia método y patrón de URI con una operación. El diseño debe evitar rutas ambiguas y mantener identificadores estables. Los controladores traducen HTTP a casos de uso, pero no deberían contener toda la lógica. Separar dominio e infraestructura facilita pruebas y reutilización fuera del canal web.

Los parámetros de ruta, consulta, cabecera y cuerpo tienen semánticas diferentes. Un identificador de recurso encaja en la ruta; filtros y paginación suelen ir en la consulta; metadatos de protocolo o negociación, en cabeceras; representaciones complejas, en el cuerpo. Esta es una convención, no una ley absoluta, pero mejora consistencia.

12.3. Validación, autenticación y autorización

Validar consiste en comprobar forma, tipo, rango y reglas de negocio. Autenticar prueba identidad; autorizar decide si esa identidad puede ejecutar la operación sobre ese recurso. La autorización debe realizarse en el servidor y cerca del caso de uso. Comprobar solo que el usuario está autenticado no evita acceso horizontal a registros de otro usuario.

La validación debe imponer listas permitidas, tamaños máximos y límites de profundidad antes de procesar datos. Los mensajes de error deben ser útiles sin revelar estructuras internas. La normalización debe ser coherente: transformar antes de validar o después puede producir resultados distintos, especialmente en identificadores y texto Unicode.

12.4. Persistencia y transacciones

Las consultas deben parametrizarse para evitar inyección SQL. Un ORM facilita mapeo, pero no elimina consultas inseguras, problemas N+1 ni autorización. Las transacciones agrupan cambios que deben confirmarse o deshacerse. En sistemas distribuidos no existe una transacción local que abarque automáticamente todos los servicios; se utilizan patrones como outbox, sagas, compensaciones e idempotencia.

La paginación evita respuestas ilimitadas. La basada en desplazamiento es sencilla, pero puede ser costosa e inconsistente bajo cambios; la basada en cursor ofrece continuidad más estable. Las APIs deben definir orden determinista, límites máximos y comportamiento ante cursores inválidos.

12.5. Gestión de errores y observabilidad

Un error esperado de validación no debe registrarse como fallo interno con traza completa. Los errores deben clasificarse y mapearse a respuestas coherentes. Un identificador de correlación permite comunicar al usuario un código sin exponer detalles y localizar la traza en los sistemas de observabilidad.

Logs, métricas y trazas cumplen funciones diferentes. Los logs describen eventos; las métricas agregan series cuantitativas; las trazas siguen una petición entre componentes. Los datos sensibles deben minimizarse y enmascararse. Registrar cuerpos completos, tokens o identificadores sanitarios sin necesidad crea un nuevo repositorio de riesgo.

12.6. Sesiones y escalabilidad

Las sesiones pueden residir en el proceso, en un almacén compartido o representarse mediante tokens. El estado en memoria dificulta escalar horizontalmente; los tokens autocontenidos dificultan revocación inmediata y pueden crecer. La autenticación debe diseñarse con expiración, rotación, revocación, protección frente a robo y auditoría.

El escalado vertical aumenta recursos de un nodo; el horizontal añade instancias. Para escalar horizontalmente se necesita configuración externalizada, procesos reemplazables, almacenamiento compartido cuando corresponda y operaciones idempotentes. La alta disponibilidad no se obtiene solo duplicando servidores: deben eliminarse puntos únicos y probarse fallos.

13. COMPONENTES DISTRIBUIDOS, SERVICIOS WEB Y APIS

Un componente distribuido ofrece funcionalidad a procesos situados en espacios de memoria o nodos diferentes. La comunicación puede ser síncrona —el llamante espera respuesta— o asíncrona —publica un mensaje y continúa—. La distribución permite escalar y separar responsabilidades, pero introduce latencia, fallos parciales, duplicados, orden incierto y necesidad de contratos explícitos.

13.1. RPC y servicios web

La llamada a procedimiento remoto intenta presentar una operación remota como si fuera local. Esta abstracción es útil, pero peligrosa si oculta diferencias: una llamada local suele ser rápida y falla de forma inmediata; una remota puede tardar, agotarse, ejecutarse aunque el cliente no reciba respuesta o devolver datos incompatibles. Los contratos deben definir tiempos máximos, reintentos, idempotencia y versionado.

Los servicios web SOAP utilizan mensajes XML y contratos WSDL. Pueden aplicar WS-Security, XML Signature, cifrado XML y otras especificaciones. Son adecuados cuando se requieren contratos formales y ecosistemas empresariales consolidados. Las APIs HTTP de estilo REST suelen usar recursos, semántica HTTP y representaciones JSON o XML. REST no es un protocolo ni un sinónimo de “JSON sobre HTTP”.

13.2. Restricciones REST

El estilo arquitectónico REST se basa en cliente-servidor, ausencia de estado de sesión en cada interacción, posibilidad de caché, interfaz uniforme, sistema en capas y código bajo demanda opcional. La interfaz uniforme incluye identificación de recursos, manipulación mediante representaciones, mensajes autodescriptivos e hipermedia como motor del estado de la aplicación. Muchas APIs denominadas REST cumplen solo una parte de estas restricciones.

El modelado de recursos evita rutas con verbos arbitrarios cuando la semántica puede expresarse mediante métodos. Sin embargo, no toda operación de negocio encaja de forma natural en CRUD. En esos casos puede modelarse una acción como recurso, documentar una operación o emplear un contrato RPC. La claridad es preferible a forzar una apariencia “RESTful” que oculte el significado.

13.3. Contratos y descripción

OpenAPI describe APIs HTTP mediante operaciones, parámetros, esquemas, respuestas y seguridad. Facilita documentación, generación de clientes y pruebas, pero no garantiza por sí sola compatibilidad semántica. WSDL cumple una función contractual en servicios SOAP. JSON Schema permite describir y validar documentos JSON; XSD cumple ese papel en XML.

Un contrato debe versionarse con criterios de compatibilidad. Añadir un campo opcional suele ser compatible para consumidores tolerantes; eliminarlo, cambiar su tipo o reinterpretarlo puede romperlos. Los clientes no deben asumir que nunca aparecerán campos nuevos. El servidor no debe reutilizar un campo con significado diferente bajo el mismo nombre.

13.4. Mensajería y eventos

Una cola desacopla productor y consumidor y absorbe picos. Un sistema de publicación/suscripción distribuye eventos a múltiples receptores. La entrega puede ser “al menos una vez”, “como máximo una vez” o, bajo condiciones específicas, proporcionar garantías equivalentes a “exactamente una vez”. En la práctica, diseñar consumidores idempotentes es esencial porque los duplicados pueden aparecer por reintentos.

Un evento expresa un hecho ocurrido; un comando solicita una acción. Confundirlos genera acoplamiento: “PacienteActualizado” describe un hecho, mientras “ActualizarPaciente” ordena comportamiento. Los eventos deben incluir identificador, versión, instante y claves de correlación, y evitar exponer datos personales innecesarios.

13.5. Microservicios y modularidad

Los microservicios dividen capacidades desplegables de forma independiente, normalmente alrededor de dominios. Aportan autonomía y escalado selectivo, pero exigen automatización, observabilidad, gestión de configuración, seguridad entre servicios y gobierno de contratos. Un monolito modular puede ser mejor cuando el dominio o el equipo no justifican distribución.

Compartir una única base de datos entre todos los servicios reduce independencia y permite saltarse contratos. Separar datos mejora autonomía, pero complica consultas y consistencia. La decisión debe partir de límites de dominio y necesidades, no de una regla absoluta.

13.6. Resiliencia

Los reintentos deben limitarse, incorporar espera exponencial y aleatoriedad, y aplicarse solo a fallos transitorios y operaciones repetibles. Reintentar inmediatamente puede amplificar una caída. Un circuit breaker deja de llamar temporalmente a una dependencia fallida; límites de concurrencia evitan agotar recursos; tiempos máximos impiden esperas indefinidas.

La consistencia distribuida suele ser eventual: diferentes componentes convergen tras procesar eventos. Esto no significa aceptar cualquier inconsistencia; deben definirse invariantes que se mantienen localmente, plazos de convergencia y mecanismos de conciliación. En procesos sanitarios críticos, algunas operaciones requerirán coordinación más fuerte.

14. PUBLICACIÓN, EDICIÓN, GESTIÓN Y PERSONALIZACIÓN DE CONTENIDOS

Publicar contenidos en Internet comprende creación, revisión, aprobación, almacenamiento, presentación, distribución y retirada. Un portal corporativo debe separar contenido de presentación para permitir reutilización, accesibilidad, multicanalidad y gobierno. El proceso editorial es tan importante como la herramienta: sin responsables, versiones y caducidad, un CMS acumula información obsoleta.

14.1. Sitios estáticos y dinámicos

Un sitio estático sirve archivos previamente generados. Ofrece superficie de ataque reducida, alta capacidad de caché y despliegue sencillo. Un sitio dinámico genera o personaliza respuestas en tiempo de petición y permite edición inmediata, autenticación y datos cambiantes. Los generadores estáticos combinan contenido estructurado con plantillas durante construcción; los enfoques híbridos regeneran selectivamente.

14.2. CMS

Un sistema de gestión de contenidos —CMS— ofrece modelos de contenido, taxonomías, usuarios, permisos, flujos editoriales, versionado, plantillas, búsqueda y publicación. WordPress, Drupal y Joomla son ejemplos generalistas; existen plataformas documentales y empresariales con capacidades específicas. La elección debe considerar seguridad, accesibilidad, soporte, interoperabilidad, migración y coste total.

El modelo de contenido debe representar significado, no únicamente bloques visuales. Separar “título”, “resumen”, “cuerpo”, “fecha de vigencia”, “audiencia” y “responsable” permite reutilizar y validar. Guardar todo como HTML libre dificulta búsqueda, personalización y publicación omnicanal.

14.3. Editores y herramientas

Un editor de código como Visual Studio Code ayuda a trabajar con HTML, CSS y JavaScript mediante sintaxis, extensiones, depuración y control de versiones. Un editor WYSIWYG como CKEditor o TinyMCE permite edición visual dentro de un CMS. Herramientas de diseño como Figma producen prototipos e interfaces, pero no sustituyen necesariamente HTML accesible y probado.

La publicación profesional se integra con Git, revisión, integración continua, validación de enlaces, pruebas de accesibilidad y despliegue automatizado. El contenido puede tratarse como código —archivos versionados— o gestionarse en base de datos; ambos modelos necesitan copias de seguridad, auditoría y recuperación.

14.4. Flujos editoriales y gobierno

Los roles suelen distinguir autor, revisor, aprobador y publicador. La separación evita que cualquier editor publique información sensible o jurídicamente relevante sin control. El versionado conserva quién cambió qué y permite restaurar. La programación temporal coordina entrada y retirada; la fecha de revisión obliga a evaluar vigencia.

Las taxonomías clasifican contenido de forma controlada. Las etiquetas libres son flexibles, pero proliferan sin gobierno. Un vocabulario gestionado mejora navegación y búsqueda. Los metadatos deben tener definiciones, cardinalidad y responsables, igual que un modelo de datos.

14.5. Personalización

Personalizar consiste en adaptar contenido o presentación según perfil, contexto o comportamiento. Puede basarse en selección explícita, rol autenticado, idioma o dispositivo. Debe diferenciarse de la autorización: ocultar contenido por personalización no impide acceder a su URL. El backend debe aplicar permisos.

La personalización algorítmica requiere transparencia, minimización y control de sesgos. En un portal sanitario, no debe inferirse ni exponerse información sensible sin base y finalidad. La medición debe evitar identificadores innecesarios y respetar preferencias y obligaciones de privacidad.

14.6. Rendimiento, CDN y SEO

Una CDN acerca recursos estáticos, termina conexiones y puede cachear contenido. Deben definirse invalidación, claves de caché y protección de origen. El versionado por huella en nombres de archivo permite cachear durante largos periodos y publicar nuevas versiones sin purgas globales.

La indexación depende de títulos, estructura, enlaces, metadatos y contenido accesible. Los datos estructurados pueden ayudar a motores, pero no sustituyen contenido de calidad. En portales internos o autenticados, el SEO puede ser irrelevante; la búsqueda corporativa y la arquitectura de información pasan a primer plano.

15. WEB SEMÁNTICA, DATOS ENLAZADOS Y REPRESENTACIÓN DEL CONOCIMIENTO

La Web semántica busca que los datos publicados tengan significado explícito y relaciones procesables por máquinas. No pretende que una máquina “comprenda” como una persona, sino proporcionar identificadores, vocabularios y semánticas formales que permitan integrar, consultar e inferir conocimiento de forma controlada.

15.1. RDF

RDF representa información como triples sujeto–predicado–objeto. Un conjunto de triples forma un grafo. Sujetos y predicados suelen identificarse mediante IRI; el objeto puede ser IRI, nodo en blanco o literal. El mismo grafo puede serializarse en Turtle, RDF/XML, JSON-LD, N-Triples o formatos equivalentes. RDF no es sinónimo de XML.

@prefix ex: <https://datos.ejemplo.es/vocab/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://datos.ejemplo.es/recurso/123>
  ex:tipo "Informe" ;
  ex:fecha "2026-08-04"^^xsd:date .

El predicado también es un recurso identificado, lo que permite compartir vocabularios. Los nodos en blanco representan recursos sin IRI global en ese grafo, pero complican reconciliación. Los literales pueden incorporar idioma o tipo de datos.

15.2. RDFS y OWL

RDF Schema define vocabulario para clases, subclases, propiedades, dominio y rango. OWL 2 ofrece un lenguaje ontológico con semántica formal, equivalencias, disyunciones, restricciones y perfiles. Una ontología describe conceptos y relaciones de un dominio; no es simplemente una lista de términos.

OWL 2 define perfiles EL, QL y RL para compromisos entre expresividad y coste computacional. EL es apropiado para ontologías grandes con ciertas formas de axiomas; QL favorece consulta sobre datos relacionales; RL facilita razonamiento mediante reglas. La elección de perfil afecta a qué inferencias son computables eficientemente.

15.3. SPARQL

SPARQL consulta grafos mediante patrones. SELECT devuelve variables; CONSTRUCT genera un grafo; ASK responde booleano; DESCRIBE solicita una descripción cuya forma depende del servicio. SPARQL 1.1 incluye actualización, consultas federadas y protocolo.

SELECT ?recurso ?fecha
WHERE {
  ?recurso <https://datos.ejemplo.es/vocab/fecha> ?fecha .
  FILTER (?fecha >= "2026-01-01"^^<http://www.w3.org/2001/XMLSchema#date>)
}

Un endpoint SPARQL expuesto sin límites puede ejecutar consultas costosas o revelar relaciones sensibles. Deben aplicarse autenticación, cuotas, tiempos máximos, vistas y minimización. Publicar datos enlazados no significa publicar datos personales.

15.4. JSON-LD y datos estructurados

JSON-LD serializa RDF con una forma compatible con JSON. El @context asigna términos a IRI; @id identifica recursos; @type expresa tipos. Es útil para datos estructurados en páginas y APIs, pero un JSON ordinario no se convierte en RDF por usar nombres parecidos.

{
  "@context": {
    "ex": "https://datos.ejemplo.es/vocab/",
    "fecha": { "@id": "ex:fecha", "@type": "http://www.w3.org/2001/XMLSchema#date" }
  },
  "@id": "https://datos.ejemplo.es/recurso/123",
  "fecha": "2026-08-04"
}

Schema.org proporciona un vocabulario compartido para describir entidades en páginas, frecuentemente mediante JSON-LD, Microdata o RDFa. Microdata incorpora atributos como itemscope, itemtype e itemprop en HTML; RDFa integra expresiones RDF. La elección depende de integración y herramientas.

15.5. Linked Data

Los principios de datos enlazados promueven utilizar IRI HTTP para identificar recursos, permitir su consulta, devolver información útil y enlazar otros recursos. El valor aparece al conectar datasets y vocabularios. Sin gobierno de identificadores, procedencia y calidad, los enlaces pueden ser ambiguos o inestables.

15.6. Dominio biomédico

La representación del conocimiento biomédico utiliza terminologías y ontologías para describir conceptos clínicos, relaciones y códigos. Repositorios como BioPortal, mantenido por el National Center for Biomedical Ontology, facilitan localizar ontologías; recursos de la U.S. National Library of Medicine, como UMLS, cumplen funciones relacionadas pero no deben confundirse con la titularidad de BioPortal.

FHIR puede representarse en JSON o XML y define recursos y perfiles clínicos; no es, por ello, una tecnología de Web semántica ni utiliza JSON-LD como representación estándar principal. Existen proyectos que relacionan FHIR y RDF, pero debe distinguirse la especificación productiva de las transformaciones o trabajos complementarios.

A marzo de 2026 existían borradores RDF 1.2, mientras RDF 1.1 seguía siendo la base de recomendaciones estables ampliamente desplegadas. En material de oposición debe distinguirse una Recomendación consolidada de un Working Draft en evolución.

16. SEGURIDAD, PRIVACIDAD, RENDIMIENTO Y OPERACIÓN

La seguridad web debe incorporarse desde requisitos y diseño. TLS protege tránsito, pero no evita inyección, autorización rota, malware del cliente o exposición en logs. La defensa en profundidad combina controles de identidad, aplicación, plataforma, red, datos y operación.

16.1. Amenazas principales

XSS aparece cuando datos no confiables se interpretan como código en el navegador. Se mitiga con codificación contextual, plantillas con escape, sanitización cuando se admite HTML y CSP. La inyección SQL se evita parametrizando consultas. CSRF explota credenciales que el navegador envía automáticamente y se reduce con tokens, SameSite y comprobaciones de origen.

SSRF ocurre cuando el servidor realiza peticiones a destinos controlados por un usuario y puede alcanzar servicios internos. Deben validarse destinos, aplicar listas permitidas, resolver y comprobar direcciones, limitar protocolos y controlar red de salida. Las cargas de archivos requieren validar tamaño, tipo real, nombre, almacenamiento aislado y análisis.

La autorización rota es especialmente crítica: cambiar un identificador en la URL no debe permitir leer otro expediente. Cada consulta debe filtrar por permisos y contexto. Los identificadores no son secretos y no sustituyen controles.

16.2. Gestión de dependencias y secretos

Las dependencias deben inventariarse, actualizarse y analizarse. Un componente sin mantenimiento puede comprometer la aplicación aunque el código propio sea correcto. La lista de materiales de software —SBOM— mejora trazabilidad. Los secretos no se almacenan en repositorios, imágenes o JavaScript del cliente; se obtienen de gestores y se rotan.

16.3. Privacidad

La minimización exige recoger y conservar solo datos necesarios. Telemetría, analítica y logs también pueden contener datos personales. Deben definirse finalidad, acceso, retención y eliminación. Los entornos de desarrollo y prueba no deberían usar copias reales sin medidas adecuadas.

En una aplicación sanitaria, mostrar datos en caché después del cierre, incluir identificadores en URL o registrar cuerpos completos puede producir exposición. Las URL viajan a historial, logs y referencias; los datos sensibles deben evitarse en consultas cuando exista alternativa.

16.4. Rendimiento

El rendimiento se mide desde la experiencia del usuario y desde el servidor. Reducir solicitudes, comprimir, cachear, optimizar imágenes, dividir código y evitar trabajo en hilo principal son medidas habituales. HTTP/2 y HTTP/3 cambian algunos compromisos, pero no eliminan necesidad de optimizar.

La latencia domina muchas interacciones. Un servicio rápido en laboratorio puede ser lento si encadena llamadas. Presupuestos de tiempo por dependencia, paralelismo controlado, caché e índices ayudan. La optimización debe basarse en medición, no en intuición.

16.5. Disponibilidad y despliegue

Los despliegues progresivos reducen riesgo: rolling, blue-green o canary. Deben existir comprobaciones de salud, retirada ordenada, migraciones compatibles y reversión. Una comprobación superficial que solo devuelve 200 no garantiza acceso a dependencias críticas; una demasiado profunda puede expulsar nodos por fallos ajenos.

Las migraciones de base deben permitir coexistencia temporal de versiones. El patrón expandir-migrar-contraer añade primero estructuras compatibles, migra y retira después. Cambiar API y base de forma incompatible en un único paso dificulta despliegue sin interrupción.

16.6. Observabilidad y respuesta

Los indicadores técnicos deben vincularse a objetivos de servicio: disponibilidad, latencia, tasa de errores y saturación. Alertar por cada evento genera ruido; deben definirse umbrales y ventanas. Las trazas ayudan a localizar dependencia lenta, pero requieren muestreo y protección de datos.

17. APLICACIÓN EN EL SAS Y CLAVES DE EXAMEN

En el Servicio Andaluz de Salud, las tecnologías web permiten portales, aplicaciones corporativas, cuadros de mando, formularios, APIs e integración. El análisis debe evitar atribuir a un producto concreto arquitecturas no documentadas. Es más seguro razonar por requisitos: protección de datos de salud, identidad corporativa, accesibilidad, interoperabilidad, trazabilidad, continuidad y rendimiento.

17.1. Escenario de aplicación clínica

Una aplicación que consulta citas puede presentar HTML accesible, ejecutar JavaScript para filtros y llamar mediante GET a una API. La API autentica al profesional, verifica autorización sobre el paciente, consulta el sistema fuente y devuelve una representación controlada. TLS protege el tránsito; los registros omiten tokens y minimizan identificadores; la interfaz no almacena datos clínicos innecesarios.

17.2. Interoperabilidad

XML y JSON son formatos; la interoperabilidad requiere modelos, códigos, perfiles y reglas compartidos. SOAP/WSDL puede aparecer en integraciones contractuales; APIs REST sobre HTTP son habituales; mensajería permite desacoplar. Elegir un formato no resuelve identidad, semántica, versionado ni seguridad.

17.3. Accesibilidad y canal público

Los servicios públicos deben diseñarse para diversidad de usuarios, dispositivos y tecnologías asistivas. HTML semántico, navegación por teclado, contraste, mensajes de error asociados y diseño adaptativo son requisitos transversales. JavaScript debe mejorar la interacción sin ocultar el estado o romper el foco.

La personalización no debe crear barreras: una preferencia de idioma o tamaño puede almacenarse, pero el contenido esencial debe seguir disponible. Los documentos descargables también requieren accesibilidad y vigencia.

17.4. Seguridad sanitaria

La autenticación debe integrarse con mecanismos corporativos cuando corresponda, pero la aplicación conserva responsabilidad de autorización. El rol general puede no bastar: puede ser necesario considerar centro, relación asistencial, finalidad y contexto. Los accesos se auditan con proporcionalidad y protección.

Los datos de salud no deben incluirse en herramientas analíticas externas sin evaluación. Las capturas de error, trazas de frontend y servicios de sesión pueden transferir información. Debe revisarse cada flujo de telemetría y contrato.

17.5. Perlas consolidadas

• HTML: lenguaje de marcado semántico, no lenguaje de programación.
• HTTP: protocolo de aplicación sin estado; REST es estilo arquitectónico.
• HTTP/2: multiplexación sobre una conexión TCP y compresión HPACK.
• HTTP/3: HTTP sobre QUIC, no “HTTP no fiable sobre UDP”.
• HTTPS: HTTP protegido por TLS; SSL está obsoleto.
• XML: bien formado es sintaxis; válido añade conformidad con DTD o esquema.
• AJAX: patrón asíncrono; no exige XML.
• Fetch: 404 y 500 no rechazan por sí solos la promesa.
• CORS: política de navegador entre orígenes, no autenticación.
• RDF: grafo de triples; JSON-LD es una serialización RDF.

La mejor estrategia de examen es asociar cada tecnología a su responsabilidad y detectar absolutos falsos: “siempre”, “únicamente”, “obligatoriamente HTTPS por REST”, “AJAX solo XML” o “HTML programa la lógica”.

18. CONCLUSIONES, IDEAS CLAVE Y MAPA CONCEPTUAL

La Web se apoya en una separación de responsabilidades. HTML estructura y aporta semántica; CSS presenta; JavaScript ejecuta comportamiento; HTTP comunica recursos y representaciones; TLS protege el canal; XML y JSON transportan datos; los servidores aplican negocio; CMS gobiernan contenido; RDF y ontologías añaden semántica explícita.

La evolución de estándares no debe memorizarse como una lista comercial. HTML es un estándar vivo; HTTP separa semántica de versiones de transporte; XML mantiene un ecosistema consolidado; ECMAScript publica ediciones anuales y evoluciona mediante TC39. Deben citarse especificaciones vigentes y distinguir recomendaciones de borradores.

Las arquitecturas cliente-servidor y distribuidas aportan escalabilidad y modularidad a cambio de fallos parciales y coordinación. La solución exige contratos, observabilidad, reintentos controlados, idempotencia y seguridad por capas. Un framework no reemplaza estas decisiones.

En cliente, la mejora progresiva, semántica y accesibilidad evitan depender de JavaScript para operaciones esenciales. En servidor, la validación, autorización y parametrización son obligatorias. AJAX mejora la interacción, pero debe gestionar errores, cancelación, concurrencia y foco.

En publicación, el contenido tiene ciclo de vida. El CMS debe modelar estructura, roles, versiones y vigencia. La personalización nunca sustituye autorización. En Web semántica, RDF, RDFS, OWL y SPARQL forman capas diferentes; una sintaxis estructurada no garantiza significado compartido.