1. INTRODUCCIÓN: INTERNET, WEB Y SISTEMAS DISTRIBUIDOS

Internet y World Wide Web son conceptos relacionados, pero no equivalentes. Internet es la infraestructura mundial formada por redes interconectadas que utilizan fundamentalmente la familia de protocolos TCP/IP. Sobre ella funcionan numerosos servicios: correo electrónico, resolución DNS, transferencia de archivos, acceso remoto, mensajería, distribución multimedia y, entre otros, la Web. La World Wide Web es uno de esos servicios y se basa en recursos identificados mediante URI, representaciones de dichos recursos y una arquitectura en la que agentes de usuario y servidores intercambian mensajes mediante HTTP.

Esta distinción es importante para una oposición técnica. HTTP no es Internet; HTML no es un protocolo de transporte; JavaScript no es el lenguaje con el que se transmite una página por la red; y XML no es una versión de HTML. Cada tecnología ocupa una función diferente dentro de una arquitectura. Una aplicación web combina protocolos, formatos, lenguajes, APIs, sistemas de almacenamiento, mecanismos de autenticación, servidores, proxies y otros componentes distribuidos.

Desde un punto de vista arquitectónico, la Web es un sistema distribuido. La interfaz visible puede ejecutarse parcialmente en el navegador; la lógica de negocio puede repartirse entre varios servicios; la persistencia puede residir en uno o más gestores de bases de datos; y el acceso exterior puede atravesar balanceadores, proxies inversos o pasarelas. Una misma operación iniciada por el usuario puede provocar llamadas a distintos componentes antes de devolver un resultado.

El modelo básico continúa siendo petición-respuesta. El cliente identifica un recurso y envía una petición HTTP. El servidor procesa esa petición y devuelve una respuesta que contiene un código de estado, metadatos y, frecuentemente, una representación. Esa representación puede ser HTML, JSON, XML, una imagen, un PDF, audio, vídeo o cualquier otro tipo de contenido convenientemente identificado mediante un tipo de medio.

La evolución de la Web ha desplazado progresivamente parte de la lógica desde el servidor hacia el navegador. Las primeras páginas eran esencialmente documentos enlazados. Más tarde aparecieron formularios, scripting, hojas de estilo, aplicaciones AJAX y, posteriormente, interfaces cliente complejas capaces de mantener estado local y comunicarse con APIs. Paralelamente, el servidor evolucionó desde la generación dinámica de páginas hacia arquitecturas de servicios, microservicios, mensajería, funciones y APIs.

Sin embargo, distribuir funciones no elimina las responsabilidades del servidor. El navegador está bajo control del usuario y no constituye una frontera de confianza. Una validación realizada mediante JavaScript mejora la experiencia de uso, pero no protege la aplicación: el servidor debe validar de nuevo los datos, autenticar al usuario, comprobar sus autorizaciones y aplicar todas las reglas de negocio relevantes.

En el contexto del Servicio Andaluz de Salud, estas tecnologías deben considerarse además bajo exigencias propias del sector público y sanitario: confidencialidad, integridad, disponibilidad, trazabilidad, accesibilidad, interoperabilidad y continuidad de servicio. Una aplicación puede ser técnicamente funcional y, aun así, resultar inaceptable si expone información clínica, carece de autorización adecuada, no es accesible o no ofrece mecanismos suficientes de recuperación frente a fallos.

2. ARQUITECTURAS WEB, RECURSOS, URI Y DISTRIBUCIÓN POR CAPAS

2.1. Arquitectura cliente-servidor

La arquitectura web clásica responde al modelo cliente-servidor. El cliente inicia una interacción y el servidor ofrece uno o varios servicios. En el caso habitual, el navegador resuelve primero el nombre del servidor mediante DNS, establece la comunicación de transporte correspondiente, negocia TLS si utiliza HTTPS y comienza el intercambio HTTP.

El término servidor puede utilizarse en varios sentidos. Puede designar una máquina física o virtual, un proceso que escucha peticiones, una aplicación, un contenedor o un rol lógico. Del mismo modo, un servidor web puede actuar simultáneamente como cliente de otro servicio. Por ejemplo, el servidor que atiende la petición del navegador puede consultar un servicio de identidad, llamar a una API corporativa y acceder después a una base de datos.

2.2. Recursos, URI y URL

La Web se organiza en torno a recursos. Un recurso es una abstracción identificable: un documento, un paciente en una API, una colección de citas, una imagen, una operación o cualquier entidad que tenga sentido para el sistema. La dirección no es el propio contenido, sino un identificador mediante el que se referencia.

Una URI identifica un recurso. El concepto de URL se utiliza para URI que proporcionan información sobre cómo localizar o acceder al recurso. En la práctica cotidiana se habla con frecuencia de URL para referirse a las direcciones web.

https://servicios.ejemplo.es/api/citas/123?detalle=completo
└─ esquema ─┘ └────── autoridad ──────┘└─── ruta ───┘└── consulta ──┘

El esquema identifica el mecanismo empleado, por ejemplo https. La autoridad incluye normalmente el nombre de host y, si se especifica, el puerto. La ruta identifica una ubicación lógica dentro del servicio. La consulta, introducida mediante ?, transporta parámetros. Un fragmento introducido mediante # suele ser interpretado en el cliente y no se transmite como parte del objetivo de la petición HTTP.

Un recurso no está ligado necesariamente a una única representación. Una misma entidad puede ofrecerse como HTML para una persona, JSON para una aplicación o XML para una integración. Esta separación entre recurso y representación resulta esencial para comprender HTTP y las arquitecturas REST.

2.3. Arquitecturas de dos, tres y múltiples niveles

La arquitectura por capas busca reducir el acoplamiento. La capa de presentación se ocupa de la interacción; la capa de aplicación coordina casos de uso; el dominio contiene las reglas fundamentales; y la infraestructura se relaciona con bases de datos, mensajería o servicios externos. La división concreta varía según el proyecto, pero el principio permanece: cada parte debe poseer responsabilidades bien delimitadas.

2.4. Renderizado en servidor, cliente e híbrido

En un modelo tradicional, el servidor procesa la petición y genera el HTML completo. Se habla de server-side rendering. En una aplicación de página única o SPA, una parte importante de la interfaz se ejecuta en el navegador y obtiene información desde APIs. Existen también estrategias híbridas que generan inicialmente HTML en el servidor y posteriormente activan componentes interactivos en el cliente.

No debe afirmarse que uno de estos modelos sea siempre superior. El renderizado en servidor simplifica ciertos escenarios de carga inicial, accesibilidad e indexación. Una interfaz intensiva en cliente puede ofrecer transiciones rápidas una vez descargada y facilitar aplicaciones interactivas complejas, pero incrementa el código ejecutado por el navegador. Los modelos híbridos intentan combinar ventajas a cambio de una cadena de construcción y despliegue más compleja.

2.5. Intermediarios

La petición del usuario no tiene por qué llegar directamente a la aplicación. Un proxy inverso recibe peticiones en nombre de uno o varios servidores. Puede terminar TLS, distribuir tráfico, aplicar reglas y ocultar la topología interna. Un balanceador reparte carga entre varias instancias. Una caché conserva respuestas reutilizables. Una CDN acerca contenido a los consumidores. Un WAF aplica controles de seguridad sobre tráfico web. Una API gateway centraliza aspectos como autenticación, límites de uso o encaminamiento.

Estos componentes mejoran escalabilidad y operación, pero añaden aspectos que deben gestionarse. Por ejemplo, la dirección observada por la aplicación podría corresponder al último proxy y no al usuario. Las cabeceras utilizadas para transmitir información de reenvío solo deben confiarse cuando proceden de intermediarios controlados. También es necesario correlacionar registros para seguir una petición a través de todos los componentes.

2.6. Arquitectura distribuida y fallos parciales

En un programa monolítico, un fallo suele manifestarse dentro de un mismo proceso. En un sistema distribuido puede fallar un servicio mientras el resto sigue funcionando; una petición puede llegar tarde; una respuesta puede perderse; un consumidor puede procesar dos veces un mensaje; o una base de datos puede estar disponible para unas operaciones y no para otras. Esta realidad obliga a diseñar tiempos máximos, reintentos, idempotencia, supervisión y degradación controlada.

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

3.1. Concepto

HTML, HyperText Markup Language, es el lenguaje de marcado fundamental de la Web. Describe la estructura y la semántica de un documento mediante elementos, atributos y relaciones jerárquicas. No es un lenguaje de programación: no define por sí mismo algoritmos generales, estructuras de control o un modelo de ejecución comparable al de JavaScript.

El navegador analiza el HTML y genera un árbol de objetos que forma parte del DOM. CSS puede seleccionar esos elementos y establecer reglas visuales. JavaScript puede consultar y modificar el DOM, responder a eventos y utilizar APIs del navegador. Son tecnologías complementarias, pero diferenciadas.

3.2. Evolución histórica

HTML surgió unido a los primeros trabajos de la World Wide Web. Con el crecimiento de Internet se fueron formalizando sus características. HTML 2.0 constituyó una de las primeras especificaciones consolidadas. HTML 3.2 incorporó características que ya se utilizaban en navegadores de la época. HTML 4 y, posteriormente, HTML 4.01 promovieron una mayor separación entre contenido y presentación, dejando progresivamente a CSS el control visual.

HTML 4.01 se publicó en variantes como Strict, Transitional y Frameset. La variante estricta favorecía una separación más limpia entre estructura y presentación; Transitional facilitaba migración desde prácticas anteriores; Frameset contemplaba documentos basados en marcos, técnica posteriormente abandonada para el diseño moderno.

XHTML 1.0 reformuló HTML 4.01 utilizando reglas XML. Esto imponía una sintaxis más disciplinada: elementos correctamente anidados, atributos adecuadamente delimitados y cierre explícito conforme a XML. XHTML no debe confundirse con una simple versión visual de HTML: su relación con XML afecta al modelo de sintaxis y procesamiento.

HTML5 supuso un cambio importante. Incorporó un modelo detallado de análisis, elementos semánticos, soporte nativo para audio y vídeo, canvas, formularios enriquecidos y un ecosistema de APIs relacionado con las aplicaciones web. El objetivo no era únicamente añadir etiquetas, sino mejorar interoperabilidad y describir de forma precisa cómo deben procesar los navegadores incluso determinados errores.

3.3. El HTML Living Standard

El estado actual no se entiende adecuadamente como una serie de versiones cerradas que deban reemplazarse periódicamente con un número mayor. Tras HTML5, HTML 5.1 y HTML 5.2, el mantenimiento efectivo se articula como HTML Living Standard, desarrollado de manera continua por WHATWG. La especificación se actualiza conforme evolucionan funcionalidades e interoperabilidad de los navegadores. :contentReference[oaicite:1]{index=1}

Por tanto, afirmar que HTML5 ha sido formalmente sustituido por “HTML6” resulta incorrecto. El término HTML5 sigue apareciendo en documentación, formación y preguntas históricas, pero al estudiar el estado del arte conviene conocer el modelo de estándar vivo.

3.4. El doctype moderno

Un documento HTML moderno comienza habitualmente con <!doctype html>. Su finalidad práctica es hacer que los navegadores utilicen el modo de estándares. A diferencia de declaraciones históricas de HTML 4 o determinados documentos XHTML, esta declaración no sirve para indicar una DTD externa de HTML5.

<!doctype html>
<html lang="es">
  <head>
    <meta charset="utf-8">
    <title>Portal sanitario</title>
  </head>
  <body>
    <h1>Información del servicio</h1>
    <p>Contenido principal del documento.</p>
  </body>
</html>

El atributo lang comunica el idioma principal. meta charset="utf-8" establece la codificación. El elemento title proporciona el título documental. El contenido visible se organiza en body. El navegador puede corregir determinados errores sintácticos al construir el DOM, pero que un navegador consiga mostrar una página no significa que el documento sea semánticamente correcto.

4. HTML MODERNO: ESTRUCTURA, SEMÁNTICA, FORMULARIOS, MULTIMEDIA Y DOM

4.1. Elementos y modelo de contenido

Los documentos HTML forman una estructura jerárquica. Un elemento puede contener texto y otros elementos, pero no cualquier combinación es válida. El estándar utiliza categorías y modelos de contenido para determinar qué descendientes son admisibles. En enseñanza clásica se hablaba de elementos “de bloque” y “en línea”; esa clasificación puede resultar útil visualmente, pero para razonar con precisión debe atenderse al modelo de contenido del elemento.

Por ejemplo, span representa un contenedor genérico de contenido de frase. No es correcto utilizarlo como contenedor arbitrario para estructura de flujo incompatible, como un párrafo completo. De forma análoga, elegir una etiqueta solo por la apariencia que el navegador le aplica por defecto conduce a documentos poco semánticos.

4.2. Semántica estructural

HTML dispone de elementos que expresan significado: encabezados, navegación, secciones, artículos, cabeceras, pies, figuras, citas, listas, tablas y formularios. El marcado semántico permite a navegadores, buscadores, tecnologías de asistencia y otras herramientas comprender mejor la organización de la información.

La semántica no debe confundirse con la Web semántica basada en RDF y ontologías. HTML semántico mejora la descripción de la estructura documental; RDF y OWL permiten representar relaciones y conocimiento en un modelo formal orientado al procesamiento de datos.

La jerarquía de encabezados contribuye a describir la organización del documento. Las listas deben utilizarse para conjuntos de elementos relacionados. Las tablas se reservan para información tabular y no como mecanismo general de maquetación. Los enlaces deben expresar destinos comprensibles. La presentación debe delegarse fundamentalmente en CSS.

4.3. Formularios

Los formularios constituyen uno de los puntos de interacción más importantes. El elemento form agrupa controles y define el mecanismo de envío. Los elementos de entrada incluyen campos de texto, contraseñas, números, fechas, controles de selección, botones, áreas de texto y otras variantes.

El elemento input utiliza el atributo type para seleccionar comportamientos diferentes: text, password, hidden, checkbox, radio, date, email, number, button o submit, entre otros. Un desplegable no se obtiene utilizando type="select"; se utiliza el elemento select con sus opciones.

Los tipos especializados ofrecen ayudas de interfaz y validación básica, pero la validación del navegador no sustituye a la validación del servidor. Un atacante puede construir directamente una petición HTTP y omitir cualquier restricción declarada en HTML o JavaScript.

Los controles deben asociarse a etiquetas significativas. El atributo name determina habitualmente el nombre con que se envía un valor. Los atributos como required, min, max o pattern permiten restricciones declarativas, siempre entendidas como ayuda de interfaz y no como mecanismo de seguridad.

4.4. Multimedia

HTML moderno incorpora audio y vídeo sin depender necesariamente de plugins externos. El navegador puede elegir entre distintas fuentes y formatos compatibles. La aplicación debe proporcionar controles y alternativas cuando sean necesarias. La reproducción automática está restringida en muchos escenarios por políticas del navegador y puede resultar problemática desde el punto de vista de accesibilidad y experiencia de usuario.

Para imágenes responsivas pueden utilizarse mecanismos como srcset, sizes o picture. Una imagen informativa necesita una alternativa textual adecuada; una imagen puramente decorativa se trata de manera distinta. Estos conceptos enlazan con el tema específico de accesibilidad y usabilidad, pero forman parte de un desarrollo HTML correcto.

4.5. Canvas y SVG

canvas proporciona una superficie en la que JavaScript puede dibujar gráficos de forma imperativa. Resulta apropiado para determinados gráficos dinámicos, visualizaciones o juegos, pero los objetos dibujados no forman automáticamente una estructura semántica equivalente en el DOM.

SVG representa gráficos vectoriales mediante elementos estructurados. Puede estilizarse, integrarse con eventos y mantener una representación declarativa de sus objetos. No se trata de que uno sustituya siempre al otro: canvas y SVG resuelven necesidades diferentes.

4.6. DOM

El Document Object Model representa el documento mediante nodos y objetos manipulables. JavaScript puede localizar elementos, leer atributos, cambiar contenido, crear nodos, eliminar elementos y registrar manejadores de eventos. El DOM no es JavaScript: es una API del entorno web a la que JavaScript accede.

Esta distinción aparece frecuentemente en preguntas conceptuales. ECMAScript define el lenguaje; las especificaciones del entorno proporcionan DOM, Fetch, almacenamiento, temporizadores y otras APIs. Otro entorno JavaScript puede implementar APIs distintas sin dejar de utilizar ECMAScript como lenguaje.

5. HTTP: FUNDAMENTOS, MENSAJES, MÉTODOS, CÓDIGOS Y REPRESENTACIONES

5.1. Naturaleza del protocolo

HTTP, Hypertext Transfer Protocol, es un protocolo de aplicación basado en mensajes de petición y respuesta. Sus principales versiones comparten una semántica común: métodos, códigos de estado, campos y conceptos como recursos, representaciones o caché. La especificación moderna separa esta semántica común de las particularidades de cada versión de mensajería. RFC 9110 constituye la referencia central de semántica HTTP. :contentReference[oaicite:4]{index=4}

HTTP es un protocolo sin estado de sesión a nivel de protocolo. Una petición contiene la información necesaria para interpretarla conforme a sus campos y al estado del recurso. Las aplicaciones pueden construir sesiones mediante cookies, tokens o almacenamiento servidor, pero ese mecanismo es una capa superior.

5.2. Petición y respuesta

Una petición identifica un método, un objetivo y metadatos. Una respuesta comunica un código de estado, campos y opcionalmente un cuerpo. El formato concreto de serialización cambia entre HTTP/1.1, HTTP/2 y HTTP/3, pero la semántica de alto nivel permanece.

GET /api/citas/123 HTTP/1.1
Host: servicios.ejemplo.es
Accept: application/json

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

{"id":123,"estado":"confirmada"}

La línea y cabeceras anteriores ilustran HTTP/1.1. En HTTP/2 y HTTP/3 la codificación sobre la red es distinta y no debe imaginarse como las mismas líneas de texto circulando literalmente. Sin embargo, conceptos equivalentes continúan presentes.

5.3. Métodos HTTP

“Seguro” no significa cifrado. Un método seguro se define porque su semántica es esencialmente de lectura y el cliente no solicita un cambio de estado del servidor. “Idempotente” significa que repetir varias veces una petición idéntica tiene el mismo efecto pretendido que efectuarla una vez. Son conceptos diferentes.

5.4. Códigos de estado

Los códigos se agrupan por familias. Los 1xx son respuestas informativas; 2xx expresan resultados satisfactorios; 3xx se relacionan con redirección y mecanismos de reutilización; 4xx indican que la petición no puede completarse por condiciones atribuibles al lado cliente o al recurso solicitado; y 5xx representan fallos del servidor al procesar una petición que, en otro caso, podría ser válida.

Algunos códigos habituales son 200 OK, 201 Created, 204 No Content, 301 Moved Permanently, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 500 Internal Server Error, 502 Bad Gateway y 503 Service Unavailable.

El nombre histórico 401 Unauthorized puede inducir a confusión: se utiliza en el contexto de autenticación requerida o no válida, mientras que 403 expresa que el servidor comprende la petición pero rehúsa autorizarla. La aplicación debe evitar exponer información sensible mediante diferencias innecesarias en mensajes de error.

5.5. Cabeceras y tipos de contenido

Los campos HTTP transportan metadatos. Content-Type identifica el tipo de medio del contenido. Accept expresa preferencias del cliente sobre representaciones. Authorization puede transportar credenciales definidas por un esquema de autenticación. Cache-Control controla reutilización. ETag proporciona un validador de representación. Location puede indicar una URI asociada a determinadas respuestas.

Un servicio no debe inferir el formato solo por la extensión del recurso. El tipo de contenido debe declararse correctamente. Esto favorece interoperabilidad y también seguridad, ya que interpretaciones ambiguas pueden llevar al navegador o a intermediarios a procesar datos de forma inesperada.

6. VERSIONES DE HTTP: HTTP/0.9, 1.0, 1.1, 2 Y 3

6.1. HTTP/0.9

La forma inicial de HTTP era extremadamente simple. El cliente solicitaba un documento y recibía básicamente su contenido. Carecía del sistema moderno de cabeceras, métodos y códigos de estado. Su interés actual es histórico: permite comprender cómo el protocolo evolucionó desde la recuperación de hipertexto hacia una plataforma general de aplicaciones.

6.2. HTTP/1.0

HTTP/1.0 consolidó mensajes con versión, métodos, códigos de estado y campos de cabecera. Permitió intercambiar distintos tipos de contenido y no únicamente documentos HTML. El uso habitual de conexiones no persistentes implicaba crear nuevas conexiones para múltiples recursos, generando un coste considerable cuando una página requería numerosas imágenes y otros ficheros.

6.3. HTTP/1.1

HTTP/1.1 mejoró la reutilización de conexiones y formalizó numerosas capacidades que marcaron la Web durante décadas. La persistencia de conexiones permite servir múltiples intercambios sin crear una conexión nueva para cada recurso. El campo Host posibilita alojar múltiples sitios bajo una misma dirección de red. También se consolidaron mecanismos de caché, transferencias, negociación y peticiones condicionales.

La especificación vigente de mensajería HTTP/1.1 se recoge en RFC 9112. En 2026, RFC 9931 actualizó requisitos de seguridad relacionados con determinadas transiciones optimistas de protocolo mediante Upgrade, recordando que incluso protocolos maduros continúan recibiendo aclaraciones de seguridad. :contentReference[oaicite:5]{index=5}

6.4. Limitaciones operativas de HTTP/1.1

Una aplicación moderna necesita numerosos recursos y peticiones. HTTP/1.1 permite mantener conexiones, pero la gestión de múltiples solicitudes concurrentes sobre una misma conexión tiene limitaciones. Los navegadores recurrieron históricamente a varias conexiones paralelas por origen para aumentar concurrencia.

No debe confundirse este problema con la semántica HTTP. La necesidad de varias conexiones deriva del modo de transporte de mensajes en HTTP/1.1, no de que GET o POST tengan diferente significado.

6.5. HTTP/2

HTTP/2 conserva la semántica HTTP y cambia de forma profunda el formato de transporte. Utiliza una capa de framing binario y permite múltiples streams lógicos multiplexados sobre una misma conexión. Así puede intercalar mensajes correspondientes a diferentes solicitudes y respuestas.

HTTP/2 utiliza HPACK para comprimir campos de cabecera. La multiplexación reduce la necesidad de abrir numerosas conexiones paralelas y evita determinadas limitaciones de HTTP/1.1 a nivel de aplicación.

No obstante, HTTP/2 utiliza normalmente TCP. Si TCP pierde un segmento, la entrega ordenada del flujo puede afectar temporalmente a los diferentes streams multiplexados en esa conexión. HTTP/2 resuelve el bloqueo entre respuestas característico de HTTP/1.1 en su capa, pero no elimina el comportamiento de entrega ordenada de TCP.

RFC 9113 especifica HTTP/2 y sustituyó a la especificación original RFC 7540. :contentReference[oaicite:6]{index=6}

6.6. HTTP/3

HTTP/3 vuelve a conservar la semántica HTTP, pero la transporta sobre QUIC. QUIC funciona sobre datagramas UDP e integra establecimiento seguro mediante TLS 1.3 en su diseño. Los streams de QUIC permiten que la pérdida que afecta a uno no provoque necesariamente el mismo bloqueo de entrega sobre otros streams independientes.

HTTP/3 utiliza QPACK para compresión de campos. QPACK se diseña teniendo en cuenta las características de QUIC y no debe confundirse con HPACK, propio de HTTP/2.

RFC 9114 especifica HTTP/3. :contentReference[oaicite:7]{index=7}

7. ESTADO, CACHÉ, COOKIES, CORS Y SEGURIDAD HTTP

7.1. HTTP sin estado y sesiones

Decir que HTTP es stateless no significa que las aplicaciones no puedan recordar al usuario. Significa que la gestión de una conversación no forma parte del estado obligatorio mantenido por HTTP entre peticiones. Las aplicaciones implementan ese estado utilizando mecanismos adicionales.

Un esquema clásico genera un identificador de sesión aleatorio, lo envía al navegador mediante una cookie y mantiene en el servidor la información asociada. Otra arquitectura puede enviar credenciales o tokens en cada petición. Cada modelo tiene implicaciones diferentes para revocación, escalabilidad, seguridad, privacidad y tiempo de vida.

Cuando se despliega una aplicación sobre varios nodos, una sesión almacenada exclusivamente en memoria local plantea un problema: la siguiente petición podría dirigirse a otra instancia. Las opciones incluyen afinidad de sesión, almacenes compartidos o diseños que reduzcan el estado conversacional.

7.2. Cookies

Una cookie es un pequeño dato que el servidor puede solicitar al agente de usuario que almacene y vuelva a enviar bajo determinadas condiciones. Las cookies se utilizan para sesiones, preferencias y otros fines, pero no deben considerarse un almacén privado inaccesible para el cliente.

Entre los atributos relevantes se encuentran Secure, que restringe su transmisión a canales seguros; HttpOnly, que impide el acceso mediante APIs JavaScript ordinarias; y SameSite, que controla determinados contextos de envío entre sitios. Deben configurarse explícitamente según la finalidad y el modelo de amenazas.

Una cookie HttpOnly reduce el riesgo de que un script inyectado lea directamente el valor, pero no corrige una vulnerabilidad XSS ni evita que el navegador realice operaciones autenticadas. La seguridad exige varias capas.

7.3. Caché

La caché permite reutilizar respuestas para reducir latencia, ancho de banda y carga de servidor. HTTP ofrece directivas mediante Cache-Control, fechas y validadores.

ETag es un validador asociado a una representación. Un cliente que conserva una copia puede enviar If-None-Match. Si la representación sigue siendo válida, el servidor puede devolver 304 Not Modified en lugar de transmitir nuevamente el cuerpo.

En aplicaciones sanitarias debe prestarse especial atención a la caché de información sensible. Un buen mecanismo para contenido público no debe aplicarse mecánicamente a historias clínicas, resultados o información personal. Las directivas deben definirse en función de la naturaleza del recurso.

7.4. Política del mismo origen

Los navegadores aplican la Same-Origin Policy para limitar la interacción entre documentos o recursos de orígenes diferentes. De manera simplificada, un origen se determina por esquema, host y puerto. Cambiar de HTTP a HTTPS, cambiar de subdominio o utilizar un puerto diferente puede producir un origen distinto.

Esta política es una defensa del navegador. No es un sistema universal de autorización de APIs. Un programa servidor, una herramienta de línea de comandos o un atacante no están obligados a respetar las limitaciones que aplica un navegador a JavaScript.

7.5. CORS

CORS, Cross-Origin Resource Sharing, permite que un servidor declare mediante campos HTTP qué accesos entre orígenes autoriza al navegador. Dependiendo del método y de los campos empleados, el navegador puede efectuar una petición previa preflight con OPTIONS antes de enviar la petición efectiva.

CORS no autentica al usuario ni decide qué operaciones de negocio puede ejecutar. El servidor debe aplicar autenticación y autorización independientemente del origen declarado. Una configuración CORS excesivamente permisiva puede exponer capacidades al código ejecutado desde otros sitios, especialmente cuando se combina con credenciales.

7.6. HTTPS y TLS

HTTPS es HTTP protegido mediante TLS. TLS proporciona confidencialidad e integridad del canal y autentica normalmente al servidor mediante certificados. No convierte automáticamente en segura a la aplicación. Una aplicación HTTPS puede seguir siendo vulnerable a inyección, XSS, CSRF, errores de autorización o exposición de información.

7.7. Cabeceras de protección

Las aplicaciones modernas pueden utilizar políticas adicionales como Content Security Policy para limitar orígenes desde los que se ejecutan determinados recursos, mecanismos contra interpretación MIME incorrecta y políticas sobre transporte seguro. Su utilidad depende de una configuración coherente y no sustituye a la codificación segura de salida ni a la eliminación de vulnerabilidades.

8. XML Y TECNOLOGÍAS ASOCIADAS

8.1. Concepto y finalidad

XML, Extensible Markup Language, es un lenguaje de marcado diseñado para representar información estructurada mediante elementos, atributos y texto. A diferencia de HTML, XML no proporciona un vocabulario general destinado a representar páginas web. Es extensible: cada dominio define sus propios elementos y reglas.

XML 1.0 continúa siendo una referencia fundamental y su quinta edición permanece como Recomendación W3C. :contentReference[oaicite:8]{index=8}

<paciente id="123">
  <nombre>Ejemplo</nombre>
  <activo>true</activo>
</paciente>

XML diferencia mayúsculas y minúsculas. Cada documento debe tener un único elemento raíz. Los elementos deben anidarse correctamente. Todo elemento abierto debe cerrarse, ya sea mediante una etiqueta de cierre o mediante la forma autocerrada cuando proceda. Los atributos deben respetar la sintaxis XML.

8.2. Documento bien formado y documento válido

Un documento bien formado cumple las reglas sintácticas de XML. Un documento válido es, además, conforme con las restricciones de un vocabulario o esquema aplicable, por ejemplo DTD o XML Schema.

Todo documento válido debe estar bien formado, pero un documento bien formado puede no haber sido validado frente a ningún esquema o no satisfacer el esquema que se esperaba. Esta diferencia es una trampa clásica de examen.

8.3. DTD

Una DTD permite declarar la estructura admitida para una familia de documentos XML: elementos, relaciones y atributos. Puede ser interna o externa. Su sintaxis tiene origen propio y no se expresa como un documento XML ordinario.

Las DTD fueron fundamentales en las primeras aplicaciones XML, pero presentan limitaciones para sistemas que requieren tipos de datos ricos o modularidad basada en espacios de nombres. Continúan siendo relevantes tanto por compatibilidad como por seguridad: la resolución de entidades externas en analizadores configurados de forma insegura puede ser peligrosa.

8.4. XML Schema

XML Schema Definition o XSD permite describir vocabularios XML con un sistema de tipos más rico. Puede expresar tipos numéricos, fechas, restricciones de longitud, enumeraciones, patrones, cardinalidades, estructuras complejas y reutilización de definiciones.

XSD está expresado utilizando sintaxis XML y se integra con espacios de nombres. La validación mediante XSD es especialmente útil cuando varios sistemas necesitan compartir contratos estructurales precisos.

8.5. Espacios de nombres

Los XML Namespaces resuelven colisiones cuando se combinan vocabularios distintos. Un prefijo se asocia a una URI de espacio de nombres y permite distinguir elementos que podrían tener el mismo nombre local pero diferente significado.

<doc xmlns:clin="https://ejemplo.es/clinica"
     xmlns:adm="https://ejemplo.es/administracion">
  <clin:estado>activo</clin:estado>
  <adm:estado>validado</adm:estado>
</doc>

El prefijo utilizado en el documento es una abreviatura; la identidad semántica viene determinada por el espacio de nombres al que se enlaza. La especificación de Namespaces in XML constituye la referencia para este mecanismo. :contentReference[oaicite:10]{index=10}

8.6. XPath

XPath es un lenguaje de expresiones para seleccionar nodos y obtener valores dentro de estructuras XML. Constituye una base utilizada también por otras tecnologías XML.

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

Una expresión XPath debe considerar los espacios de nombres. Un nombre escrito sin prefijo en una consulta no coincide automáticamente con elementos que pertenecen a un espacio de nombres predeterminado.

8.7. XSLT

XSLT es un lenguaje de transformación. Una hoja de estilo XSLT contiene reglas y plantillas que procesan árboles XML y pueden producir XML, HTML, texto u otras representaciones. No debe confundirse con CSS: CSS presenta contenido; XSLT transforma estructuras.

8.8. XQuery

XQuery permite consultar y construir información a partir de fuentes XML. Se orienta a operaciones más generales de consulta y composición, aunque comparte modelos y funciones con XPath.

8.9. SOAP, WSDL y ecosistema XML

SOAP utiliza XML para estructurar mensajes mediante un sobre que puede contener cabecera y cuerpo. Puede transportarse sobre HTTP y otros mecanismos. WSDL describe servicios: operaciones, mensajes, tipos y puntos de acceso. Las extensiones WS-* cubren necesidades como seguridad, direccionamiento o políticas.

SOAP y REST no son versiones consecutivas de una misma tecnología. SOAP constituye un protocolo de mensajería con un ecosistema contractual; REST es un estilo arquitectónico. Un servicio puede utilizar HTTP y XML sin ser SOAP, y una API REST puede intercambiar XML, JSON u otras representaciones.

8.10. Seguridad XML

Los analizadores XML deben configurarse con especial cuidado. La resolución de entidades externas puede permitir ataques XXE, capaces de provocar acceso a recursos locales, solicitudes a sistemas internos o filtración de información. La expansión masiva o recursiva de entidades puede agotar recursos.

Cuando una aplicación no necesita DTD o entidades externas, deben deshabilitarse de acuerdo con las capacidades seguras de la biblioteca utilizada. También deben imponerse límites de tamaño, profundidad y consumo, y evitar que datos no confiables se incorporen directamente a expresiones XPath o transformaciones.

9. DESARROLLO DE APLICACIONES WEB EN EL CLIENTE

9.1. El navegador como plataforma

El desarrollo en cliente comprende el código que se ejecuta en el agente de usuario. Un navegador moderno incluye un analizador HTML, motor de estilos, motor JavaScript, pila de red, almacenamiento, sistema de eventos, APIs multimedia y controles de seguridad. Se ha convertido en una plataforma de ejecución completa.

Esto no significa que el navegador sea un entorno confiable para el servidor. El usuario puede inspeccionar el HTML, modificar JavaScript, alterar peticiones, automatizar llamadas o prescindir totalmente de la interfaz. Toda decisión de seguridad debe verificarse en un componente controlado por la organización.

9.2. Construcción de la interfaz

El navegador analiza HTML y construye el DOM. Analiza hojas CSS y obtiene las reglas necesarias para determinar estilos. A partir de estas estructuras calcula geometría y representación visual. JavaScript puede modificar el DOM o estilos, haciendo necesario recalcular partes de la página.

Un desarrollo eficiente evita realizar modificaciones innecesarias en bucles intensivos y limita trabajos costosos sobre el hilo principal. Las operaciones de red y determinadas APIs se coordinan de forma asíncrona para evitar bloquear la interacción.

9.3. Aplicaciones multipágina y SPA

En una aplicación multipágina tradicional, cada navegación solicita al servidor un nuevo documento HTML. En una SPA, el navegador mantiene una aplicación y actualiza vistas obteniendo datos mediante APIs. Existen arquitecturas intermedias y frameworks capaces de combinar renderizado de servidor y cliente.

Una SPA no elimina HTTP: normalmente aumenta la importancia de las APIs HTTP. Tampoco elimina el servidor: desplaza parte de la presentación y coordinación al navegador, mientras las reglas de negocio, persistencia y seguridad permanecen en backend.

9.4. Almacenamiento en cliente

El navegador proporciona varios mecanismos de almacenamiento. localStorage mantiene pares clave-valor asociados al origen y expone una API síncrona. sessionStorage mantiene un ámbito ligado a la sesión de navegación correspondiente. IndexedDB proporciona almacenamiento estructurado asíncrono más adecuado para cantidades mayores y modelos complejos.

No deben almacenarse secretos de larga duración en lugares accesibles a JavaScript sin analizar el riesgo. Una vulnerabilidad XSS puede ejecutar código dentro del origen y acceder a recursos a los que el script legítimo también tiene acceso.

9.5. Web Workers

Los Web Workers permiten ejecutar JavaScript fuera del hilo principal de interfaz. Son útiles para cálculos costosos que, si se ejecutaran en el hilo principal, producirían bloqueos perceptibles. Los workers ordinarios no manipulan directamente el DOM; se comunican mediante mensajes.

9.6. Service Workers

Un service worker es un tipo especial de worker con un ciclo de vida relacionado con un origen y un ámbito. Puede interceptar peticiones dentro de ese ámbito y colaborar con caché, funcionamiento sin conexión y determinadas capacidades en segundo plano. Normalmente requiere un contexto seguro.

No debe confundirse service worker con web worker. El primero puede actuar como intermediario programable de red; el segundo está orientado fundamentalmente a ejecución de cálculo en segundo plano.

9.7. Mejora progresiva

La mejora progresiva parte de una base funcional y añade capacidades cuando están disponibles. Es especialmente importante para servicios públicos, donde pueden coexistir navegadores, dispositivos, condiciones de conectividad y necesidades de accesibilidad muy diferentes.

Una función esencial no debería depender innecesariamente de un comportamiento avanzado si puede ofrecerse una alternativa robusta. Esto no implica renunciar a aplicaciones modernas, sino diseñarlas de forma resiliente.

9.8. Seguridad del lado cliente

Los principales riesgos incluyen XSS, exposición de tokens, bibliotecas vulnerables, manipulación de DOM, comunicaciones con orígenes incorrectos y almacenamiento inseguro. El cliente debe validar por experiencia de usuario, codificar adecuadamente contenido, evitar insertar HTML no confiable y aplicar las políticas de seguridad definidas por la organización.

Pero ninguna medida cliente permite al servidor confiar en una petición simplemente porque “la produjo la aplicación oficial”. Todo dato recibido es entrada no confiable hasta que ha sido validado y autorizado.

10. JAVASCRIPT Y ECMASCRIPT

10.1. JavaScript frente a ECMAScript

JavaScript es el nombre utilizado habitualmente para el lenguaje implementado por navegadores y otros entornos. ECMAScript es la especificación normalizada en ECMA-262. La edición publicada en junio de 2026 es ECMAScript 2026, decimoséptima edición. El borrador técnico continúa evolucionando para futuras ediciones. :contentReference[oaicite:11]{index=11}

ECMAScript define el lenguaje: tipos, operadores, objetos básicos, funciones, clases, promesas, módulos y demás construcciones. DOM, Fetch, Web Storage o los eventos de un navegador pertenecen a APIs del entorno anfitrión, no al núcleo de ECMA-262.

10.2. Tipos

Entre los valores primitivos se encuentran undefined, null, booleanos, números, bigint, cadenas y símbolos. Los objetos representan colecciones de propiedades y comportamiento.

El tipo Number utiliza aritmética de doble precisión para los números ordinarios, por lo que determinadas fracciones decimales no tienen una representación binaria exacta. En cálculos financieros o clínicos sensibles deben aplicarse reglas explícitas de precisión y redondeo.

10.3. Igualdad y coerción

JavaScript permite conversiones implícitas. La igualdad abstracta == puede realizar coerción entre tipos. La igualdad estricta === no aplica esa misma conversión y resulta normalmente más predecible.

3 == new Number(3)   // true
3 === new Number(3)  // false
3 === 3              // true

Un objeto creado con new Number(3) no es el mismo tipo de valor que el número primitivo 3. Comprender esta diferencia es más útil que memorizar resultados aislados.

10.4. let, const y var

let y const tienen ámbito de bloque. var posee ámbito de función y reglas históricas de elevación diferentes. const evita reasignar el enlace, pero no convierte automáticamente en inmutable al objeto referenciado.

const configuracion = { modo: "normal" };
configuracion.modo = "seguro";

El ejemplo es válido: no se ha reasignado configuracion, sino modificado una propiedad del objeto.

10.5. Funciones y cierres

Las funciones son valores de primera clase y pueden almacenarse, pasarse como argumentos y devolverse. Un closure permite que una función mantenga acceso al entorno léxico en el que fue creada.

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

const siguiente = crearContador();

Los cierres facilitan encapsulación y callbacks, pero pueden prolongar la vida de referencias. En aplicaciones que permanecen abiertas durante horas, manejadores no liberados, temporizadores y cachés ilimitadas pueden producir fugas de memoria.

10.6. Prototipos y clases

JavaScript utiliza herencia basada en prototipos. La sintaxis class ofrece una forma más familiar de declarar constructores y métodos, pero se apoya en el mismo modelo prototípico del lenguaje. No debe interpretarse como una copia exacta del modelo de clases de Java o C#.

10.7. Eventos

La interacción del usuario se expresa mediante eventos: clic, teclado, cambios en controles, carga, mensajes y muchos otros. Los manejadores se registran sobre objetos y se ejecutan cuando el entorno procesa los eventos correspondientes.

En el DOM existen fases de propagación y burbujeo que permiten delegación de eventos. Esta técnica puede evitar registrar miles de manejadores cuando múltiples elementos comparten comportamiento.

10.8. Event loop

El código JavaScript del navegador se coordina mediante un bucle de eventos. Una operación asíncrona no significa que todo el código JavaScript se ejecute simultáneamente. El entorno programa tareas y microtareas, y el motor ejecuta el código correspondiente según las reglas de la plataforma.

Las continuaciones de las promesas se procesan como microtareas. Esta característica explica determinados órdenes de ejecución que sorprenden a quien piensa únicamente en una cola FIFO simple.

10.9. Promesas y async/await

Una Promise representa un resultado que puede estar pendiente, cumplido o rechazado. async y await proporcionan una sintaxis estructurada para trabajar con promesas sin convertir la operación en síncrona.

async function cargarEstado() {
  const respuesta = await fetch("/api/estado");

  if (!respuesta.ok) {
    throw new Error(`HTTP ${respuesta.status}`);
  }

  return respuesta.json();
}

10.10. Módulos

Los módulos ECMAScript utilizan import y export. Poseen ámbito propio y permiten declarar dependencias explícitas. Las herramientas de construcción pueden analizar esas dependencias, dividir bundles y eliminar determinados elementos no utilizados.

El ecosistema de paquetes incrementa productividad, pero también la superficie de cadena de suministro. Las dependencias deben mantenerse, limitarse a las necesarias y someterse a análisis de vulnerabilidades y procedencia.

11. AJAX, XMLHTTPREQUEST Y FETCH API

11.1. Concepto AJAX

AJAX significa Asynchronous JavaScript and XML. Describe una técnica mediante la que una página ya cargada realiza comunicaciones con el servidor y actualiza partes de la interfaz sin efectuar necesariamente una navegación completa.

Aunque XML aparece en el nombre, AJAX no obliga a utilizar XML. En aplicaciones modernas es muy habitual intercambiar JSON. También pueden recibirse texto, HTML, binarios u otros formatos.

La aportación fundamental es separar el ciclo de interacción de la navegación completa. El usuario puede consultar, filtrar, guardar o actualizar información sin descargar de nuevo todo el documento. A cambio, la aplicación debe gestionar estados intermedios, errores, cancelaciones y accesibilidad de los cambios dinámicos.

11.2. XMLHttpRequest

XMLHttpRequest es la API histórica que popularizó las aplicaciones AJAX. Permite configurar método, URL, campos, tipo de respuesta y manejadores de eventos.

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();

XMLHttpRequest mantiene utilidad en aplicaciones existentes y proporciona determinados eventos de progreso. Sin embargo, para muchas operaciones modernas se prefiere Fetch API debido a su integración con promesas y otros objetos de la plataforma.

11.3. Fetch API

fetch inicia una petición y devuelve una promesa cuyo resultado es un objeto Response. El objeto incluye código de estado, campos y métodos asíncronos para consumir el cuerpo.

async function obtenerCita(id) {
  const respuesta = await fetch(`/api/citas/${encodeURIComponent(id)}`, {
    headers: {
      "Accept": "application/json"
    }
  });

  if (!respuesta.ok) {
    throw new Error(`HTTP ${respuesta.status}`);
  }

  return respuesta.json();
}

Un detalle fundamental es que fetch no rechaza la promesa simplemente porque el servidor devuelva 404 o 500. En esos casos normalmente se obtiene un Response y el programa debe revisar ok o status. La promesa se rechaza principalmente ante fallos de red, cancelación u otras condiciones equivalentes.

11.4. Cancelación

Fetch se integra con AbortSignal y AbortController. Esta posibilidad es importante en interfaces donde una operación deja de ser relevante porque el usuario ha cambiado de pantalla, ha iniciado una nueva búsqueda o se ha alcanzado un tiempo máximo definido por la aplicación.

No cancelar o ignorar peticiones antiguas puede provocar condiciones de carrera: una respuesta lenta correspondiente a una búsqueda anterior podría sobrescribir datos de una búsqueda más reciente.

11.5. AJAX y CORS

Cuando JavaScript solicita recursos de otro origen, entra en juego la política del mismo origen y, cuando proceda, CORS. El hecho de que una petición sea AJAX no otorga permiso especial. El servidor debe declarar los orígenes, métodos y campos admitidos conforme al diseño.

11.6. Estados de interfaz

Una aplicación AJAX debe representar los estados de carga, éxito, ausencia de resultados y error. Ocultar una operación asíncrona tras un indicador visual sin informar de fallos puede dejar al usuario sin saber si sus datos se han guardado.

En operaciones de modificación debe analizarse además qué ocurriría si el usuario repite la acción. Diseñar endpoints idempotentes cuando la semántica lo permite o utilizar identificadores de operación puede evitar duplicados en escenarios de reintento.

12. DESARROLLO DE APLICACIONES WEB EN EL SERVIDOR

12.1. Responsabilidades del backend

El desarrollo en servidor comprende el código ejecutado en una infraestructura controlada por la organización. Sus responsabilidades habituales incluyen autenticación, autorización, reglas de negocio, persistencia, coordinación de transacciones, integración con otros sistemas, auditoría y generación de respuestas.

La interfaz no debe constituir la única implementación de una regla. Si únicamente se oculta un botón a un usuario no autorizado pero el endpoint continúa admitiendo la operación, la aplicación sigue siendo vulnerable. Las autorizaciones se aplican en el servidor para cada acción protegida.

12.2. Servidor web y servidor de aplicaciones

Un servidor web recibe tráfico HTTP y puede servir recursos estáticos o reenviar peticiones a aplicaciones. Un servidor de aplicaciones proporciona un entorno para ejecutar lógica dinámica, gestionar componentes y ofrecer servicios adicionales. En arquitecturas actuales estas funciones pueden solaparse o distribuirse entre procesos diferentes.

Productos como nginx pueden actuar como servidor web y proxy inverso. Una aplicación Java puede ejecutarse en un servidor especializado o en un proceso embebido dentro de un contenedor. Frameworks de .NET, Java, Python, PHP, JavaScript y otros ecosistemas proporcionan modelos distintos para atender peticiones.

12.3. Pipeline de una petición

El orden concreto varía, pero esta secuencia muestra que responder a una URL no consiste únicamente en ejecutar una función. Los frameworks suelen implementar una cadena de middleware o filtros que procesan transversalmente las solicitudes.

12.4. Validación

Todo dato procedente del cliente debe considerarse no confiable: parámetros de ruta, consulta, campos HTTP, cookies, JSON, XML y datos de formulario. El servidor comprueba estructura, tipo, límites y coherencia. Posteriormente aplica reglas de negocio.

Validar que una cadena tiene aspecto de identificador no demuestra que el usuario tenga autorización para acceder al recurso identificado. Validación y autorización son controles diferentes.

12.5. Acceso a datos

Las aplicaciones web acceden a SGBD relacionales, almacenes documentales, cachés, sistemas de archivos u otros repositorios. Cuando se utiliza SQL, los valores externos deben enviarse como parámetros mediante las APIs apropiadas en lugar de concatenarse dentro de la sentencia.

La parametrización protege la estructura de la consulta frente a inyección SQL. No sustituye las autorizaciones, el principio de mínimo privilegio o las restricciones de integridad de la base de datos.

12.6. Concurrencia

Los servidores atienden múltiples peticiones. Los frameworks pueden utilizar hilos, procesos, modelos asíncronos o combinaciones de ellos. El desarrollador debe evitar condiciones de carrera sobre datos compartidos y comprender las garantías transaccionales del almacenamiento.

Una operación que primero comprueba un estado y posteriormente lo modifica puede ser incorrecta si otra petición cambia el mismo recurso entre ambos pasos. Las bases de datos y mecanismos de concurrencia deben formar parte del diseño.

12.7. Sesiones y autenticación

Una aplicación puede utilizar sesión servidor, certificados, autenticación federada, OAuth/OIDC u otros mecanismos según su contexto. La autenticación identifica o verifica al sujeto; la autorización determina qué puede hacer. Nunca deben utilizarse como sinónimos.

12.8. Observabilidad

Una aplicación operable necesita registros, métricas y trazas. Los logs deben permitir diagnosticar errores, pero no deben almacenar contraseñas, tokens o datos de salud indiscriminadamente. La trazabilidad debe diseñarse junto con las exigencias de privacidad y seguridad.

Los identificadores de correlación ayudan a seguir una operación a través de varios componentes. Las métricas muestran latencia, tasas de error, saturación o capacidad. Las trazas distribuidas permiten relacionar llamadas entre servicios.

13. COMPONENTES DISTRIBUIDOS, SERVICIOS WEB Y APIS

13.1. Concepto

Un componente distribuido ofrece funcionalidades a otros componentes a través de una red. La comunicación puede ser síncrona, cuando el solicitante espera una respuesta, o asíncrona, cuando intervienen mensajes, eventos o colas.

La distribución permite escalar y evolucionar subsistemas de manera independiente, pero requiere contratos estables. Un cambio aparentemente local en el formato de un mensaje puede romper a numerosos consumidores.

13.2. REST

REST, Representational State Transfer, es un estilo arquitectónico. Entre sus restricciones se encuentran cliente-servidor, ausencia de estado de sesión en cada interacción, caché, interfaz uniforme, sistema en capas y, opcionalmente, código bajo demanda.

REST no es sinónimo de “JSON sobre HTTP”. JSON es un formato; HTTP es un protocolo; REST es un estilo. Es posible diseñar una API HTTP que intercambie JSON sin cumplir bien las restricciones REST.

La interfaz uniforme favorece el uso coherente de recursos, métodos, representaciones y metadatos. Los identificadores representan recursos y las operaciones se expresan utilizando la semántica del protocolo.

13.3. SOAP

SOAP define una estructura XML para mensajes. El Envelope envuelve el mensaje y contiene un cuerpo; pueden existir cabeceras con metadatos adicionales. Los servicios SOAP suelen acompañarse de descripciones WSDL que formalizan operaciones, mensajes, tipos y puntos de acceso.

El ecosistema WS-* ofrece especificaciones para necesidades empresariales complejas. Aunque muchas APIs modernas utilizan REST/HTTP y JSON, SOAP continúa presente en integraciones corporativas donde existen contratos consolidados o requisitos específicos.

13.4. RPC y gRPC

Los modelos RPC presentan la interacción como invocación de procedimientos remotos. gRPC utiliza contratos de servicios y mensajes definidos generalmente mediante Protocol Buffers y emplea HTTP/2 como transporte habitual. Su enfoque difiere de REST: el contrato se organiza alrededor de métodos del servicio en lugar de una interfaz uniforme orientada a recursos.

No debe elegirse una tecnología por moda. APIs públicas, integraciones internas de alto rendimiento, compatibilidad con sistemas heredados y flujos orientados a eventos tienen requisitos diferentes.

13.5. Mensajería

Una cola o broker desacopla productor y consumidor. El productor publica un mensaje sin necesitar que el consumidor complete inmediatamente el trabajo. Esto absorbe picos de carga y facilita procesos asíncronos.

La mensajería introduce problemas propios: entrega duplicada, orden, reintentos, mensajes venenosos y consistencia. En numerosos sistemas debe asumirse que un mensaje podría recibirse más de una vez y diseñar consumidores idempotentes.

13.6. WebSocket

WebSocket proporciona un canal bidireccional persistente apropiado para escenarios en los que servidor y cliente necesitan intercambiar mensajes con baja latencia durante una sesión. No sustituye universalmente a HTTP: añade otro modelo de comunicación para casos donde la petición-respuesta resulta insuficiente.

13.7. Server-Sent Events

Los Server-Sent Events permiten mantener un flujo desde servidor hacia cliente mediante HTTP. Son apropiados cuando el sentido principal de actualizaciones es servidor-cliente y no se necesita un canal bidireccional completo.

13.8. API Gateway

Una API gateway puede centralizar autenticación, límites, observabilidad, transformación y enrutamiento. También puede convertirse en un punto crítico si concentra demasiada lógica de negocio. Las responsabilidades deben mantenerse claras.

13.9. Resiliencia

Las llamadas remotas necesitan tiempos máximos. Un servicio que espera indefinidamente puede agotar hilos o conexiones. Los reintentos solo deben aplicarse cuando la operación y el fallo lo permiten; reintentar indiscriminadamente una petición de modificación puede duplicar efectos.

Patrones como circuit breaker evitan insistir continuamente sobre un servicio que se encuentra fallando. La limitación de concurrencia y el aislamiento de recursos impiden que un componente degradado arrastre a toda la plataforma.

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

14.1. Del documento al sistema de gestión de contenidos

Publicar una página puede consistir simplemente en colocar un documento estático en un servidor. Sin embargo, los portales corporativos necesitan gestionar miles de contenidos, usuarios, versiones, permisos, fechas de vigencia y flujos de aprobación. Para ello se utilizan Content Management Systems o CMS.

Un CMS separa el contenido de muchas tareas técnicas de publicación. Los autores trabajan con modelos y editores; el sistema almacena contenido y metadatos; los responsables revisan; y la plataforma genera o sirve las representaciones finales.

14.2. Funciones de un CMS

• Modelado de tipos de contenido.
• Edición y previsualización.
• Control de usuarios, grupos y permisos.
• Versionado e historial.
• Flujos de revisión y aprobación.
• Taxonomías, categorías y etiquetas.
• Programación temporal de publicación.
• Gestión de recursos multimedia.
• Búsqueda.
• Publicación multicanal.

Un CMS no debe confundirse con un simple editor. El editor es solo una de las interfaces de creación. La gestión editorial, versionado, permisos y publicación son capacidades que caracterizan al sistema completo.

14.3. WYSIWYG

WYSIWYG significa What You See Is What You Get. Un editor WYSIWYG intenta que el aspecto mostrado durante la edición se aproxime al resultado final. Facilita que usuarios no técnicos creen contenidos sin escribir manualmente todo el marcado.

No obstante, “lo que se ve” durante la edición no puede garantizar identidad absoluta en todos los dispositivos. El diseño web es adaptable: tamaños de pantalla, fuentes, configuración del navegador y necesidades de accesibilidad pueden modificar la representación.

14.4. CMS acoplado y headless

Un CMS tradicional suele integrar administración, almacenamiento, plantillas y generación de páginas. Un headless CMS separa la gestión de contenidos de su representación y los expone mediante APIs. Distintos frontends —web, aplicación móvil o dispositivos— pueden consumir los mismos contenidos.

El enfoque headless mejora reutilización multicanal, pero desplaza responsabilidades al frontend: renderizado, navegación, previsualización, caché y optimización deben resolverse de forma explícita.

14.5. Contenido estructurado

Una práctica madura consiste en almacenar contenido según su significado en lugar de como grandes bloques visuales. Por ejemplo, una noticia puede contener título, resumen, cuerpo, fecha, autor, categoría, imagen y periodo de vigencia. Esto facilita reutilizarla en diferentes canales.

Si todo se almacena como HTML arbitrario creado por un editor, resulta más difícil transformar, buscar, validar y reutilizar la información. Los modelos estructurados también facilitan gobernanza.

14.6. Workflow editorial

Un contenido corporativo suele atravesar estados: borrador, revisión, aprobado, publicado, archivado. Las responsabilidades pueden estar separadas para evitar que cualquier usuario publique directamente información institucional.

El historial permite conocer quién cambió un contenido y recuperar versiones anteriores. En entornos sanitarios, la fecha de revisión es especialmente relevante porque información clínica o administrativa desactualizada puede inducir a error.

14.7. Política editorial

La política editorial define criterios sobre creación, selección, revisión, responsabilidad y actualización. También puede establecer mecanismos de participación y corrección. No debe limitarse a cuestiones estéticas: forma parte de la gobernanza y calidad del portal.

14.8. Publicación estática y dinámica

Un sitio estático sirve archivos previamente generados. Reduce la superficie de ejecución durante cada solicitud y puede distribuirse eficientemente mediante CDN. Un sitio dinámico genera o personaliza contenido en tiempo de petición. Entre ambos extremos existen estrategias de generación incremental, cachés y renderizado híbrido.

14.9. CDN

Una Content Delivery Network replica o almacena contenido en nodos distribuidos geográficamente. Reduce latencia y descarga los servidores de origen. La aplicación debe definir correctamente políticas de caché e invalidación.

14.10. Personalización

La personalización adapta contenido o servicios a contexto, preferencias o perfil. Puede basarse en información declarada por el usuario, historial, rol, dispositivo u otros criterios permitidos.

Personalizar no significa autorizar. Que una interfaz oculte determinada información a un perfil no evita que un atacante solicite directamente el recurso. El backend debe aplicar las autorizaciones independientemente de la personalización visual.

En el sector público, la personalización debe analizarse además desde protección de datos, transparencia, minimización y posibles efectos discriminatorios. Debe recogerse únicamente la información necesaria para la finalidad legítima definida.

15. WEB SEMÁNTICA, RDF, ONTOLOGÍAS Y DATOS ENLAZADOS

15.1. Concepto

La Web semántica persigue representar información de forma que las máquinas puedan interpretar no solo su sintaxis, sino también relaciones y significado. Esto requiere identificadores globales, vocabularios compartidos, grafos de datos y lenguajes que permitan expresar conocimiento formal.

No debe confundirse con la Web social, la personalización, el diseño responsive ni la simple utilización de tecnologías modernas. Una página puede personalizar resultados sin disponer de datos semánticos; y un conjunto RDF puede expresar semántica aunque no exista una interfaz personalizada.

15.2. RDF

RDF, Resource Description Framework, representa afirmaciones como triples:

El conjunto de triples forma un grafo. Por ejemplo, se puede expresar que una determinada organización pertenece a un territorio, que un documento tiene un autor o que un concepto mantiene una relación con otro.

RDF es un modelo abstracto y puede serializarse de distintas formas. RDF/XML utiliza XML. Turtle ofrece una sintaxis orientada a legibilidad. JSON-LD utiliza estructuras compatibles con JSON y contextos que vinculan términos con identificadores semánticos.

15.3. Estado de RDF

RDF 1.1 continúa siendo la familia de Recomendaciones W3C consolidada para producción. Durante 2026 RDF 1.2 se encuentra en proceso de estandarización y ha alcanzado estados de Candidate Recommendation Snapshot. Para una oposición conviene distinguir un estándar consolidado de una especificación todavía en evolución. :contentReference[oaicite:16]{index=16}

15.4. RDFS

RDF Schema proporciona vocabulario para describir clases, subclases, propiedades, dominios y rangos. Permite expresar organización básica del conocimiento y realizar inferencias sencillas.

Por ejemplo, si se establece que Cardiología es una subclase de ServicioSanitario y un recurso pertenece a Cardiología, puede inferirse que también pertenece a ServicioSanitario.

15.5. OWL

OWL, Web Ontology Language, ofrece un lenguaje formal para describir ontologías. Permite definir clases, propiedades, equivalencias, restricciones, cardinalidades y otras relaciones con una semántica apta para razonamiento automático.

OWL 2 es una Recomendación W3C consolidada y dispone de perfiles que equilibran expresividad y coste de razonamiento. :contentReference[oaicite:17]{index=17}

Una ontología no es simplemente una lista de palabras. Define conceptos, relaciones y restricciones que permiten interpretar datos de forma compartida.

15.6. SPARQL

SPARQL es el lenguaje de consulta para grafos RDF. Una consulta selecciona patrones de triples y obtiene vinculaciones para variables.

SELECT ?servicio
WHERE {
  ?servicio a <https://ejemplo.es/Servicio> .
}

La forma SELECT devuelve soluciones de variables. ASK devuelve un valor booleano sobre la existencia de coincidencias. CONSTRUCT produce un grafo RDF a partir de los resultados.

SPARQL 1.1 es la Recomendación W3C consolidada. SPARQL 1.2 se encuentra todavía en evolución durante 2026 y no debe presentarse como si hubiese sustituido definitivamente a la versión recomendada. :contentReference[oaicite:18]{index=18}

15.7. JSON-LD

JSON-LD expresa datos enlazados utilizando una sintaxis basada en JSON. Mediante @context se relacionan nombres compactos con IRI; @id identifica recursos y @type declara tipos.

Un documento JSON convencional no se convierte automáticamente en RDF. JSON-LD aporta las reglas necesarias para vincular términos y construir el grafo semántico.

15.8. Linked Data

Los datos enlazados promueven el uso de identificadores globales y relaciones entre recursos. La idea es superar conjuntos de datos aislados y permitir que distintas fuentes puedan referenciar conceptos compartidos.

Para una Administración Pública, esta capacidad puede mejorar interoperabilidad, publicación reutilizable y relación entre catálogos, siempre que se acompañe de gobierno del dato, control de calidad, protección de datos y vocabularios mantenidos.

15.9. Web semántica y sanidad

El ámbito sanitario es especialmente sensible a la semántica. Que dos sistemas intercambien una cadena XML o JSON no garantiza que interpreten de igual modo un diagnóstico, una unidad, un procedimiento o una observación. La interoperabilidad semántica requiere terminologías, modelos y significados compartidos.

RDF y OWL representan tecnologías generales de conocimiento; los estándares clínicos y terminologías concretas se estudian con mayor profundidad en los temas específicos de interoperabilidad sanitaria. La idea que debe quedar fijada aquí es que sintaxis compartida no equivale a semántica compartida.

16. SEGURIDAD, RENDIMIENTO Y OPERACIÓN DE APLICACIONES WEB

16.1. Seguridad por capas

Una aplicación web segura combina controles en navegador, transporte, proxy, aplicación, servicios, bases de datos y operación. Ningún control aislado es suficiente. Un WAF no corrige un fallo de autorización; TLS no evita SQL injection; y validar un formulario en JavaScript no protege el endpoint.

16.2. XSS

Cross-Site Scripting aparece cuando datos no confiables terminan interpretándose como contenido ejecutable en el contexto de una página. La defensa principal es codificar la salida según el contexto y utilizar APIs seguras que no interpreten innecesariamente cadenas como HTML.

Existen variantes reflejadas, almacenadas y basadas en DOM. Una política CSP puede reducir el impacto de determinados escenarios, pero no sustituye al tratamiento correcto de datos.

16.3. CSRF

Cross-Site Request Forgery aprovecha la capacidad del navegador para enviar automáticamente determinadas credenciales a un sitio y consigue que una víctima autenticada origine una operación no deseada. Entre las defensas se encuentran tokens antifalsificación, políticas apropiadas de cookies y verificación del contexto de la petición.

16.4. Inyección

La inyección aparece cuando los datos se mezclan con instrucciones. SQL injection es el ejemplo clásico, pero el principio se extiende a comandos, LDAP, plantillas y otros intérpretes. La solución consiste en separar datos y código utilizando APIs parametrizadas o mecanismos equivalentes.

16.5. Broken Access Control

Los fallos de control de acceso permiten ejecutar funciones o consultar datos sin autorización. Un identificador numérico en una URL no debe considerarse secreto. El servidor comprueba que el usuario actual tiene permiso sobre el objeto solicitado.

Este aspecto es crítico en sistemas sanitarios. No basta con que el enlace a una historia o informe no aparezca en la pantalla; la API debe rechazar cualquier acceso no autorizado.

16.6. SSRF

Un ataque Server-Side Request Forgery induce al servidor a realizar peticiones hacia destinos controlados por el atacante o hacia sistemas internos. Resulta especialmente peligroso cuando una aplicación acepta URL para importar imágenes, documentos o integraciones.

Las defensas incluyen limitar destinos, validar esquemas, aplicar segmentación de red y controlar redirecciones. La simple comprobación textual de que una cadena “parece una URL” no es suficiente.

16.7. Gestión de secretos

Contraseñas de bases de datos, claves privadas y secretos de API no deben incrustarse en código cliente ni almacenarse en repositorios sin protección. Las organizaciones utilizan almacenes de secretos, rotación, mínimo privilegio y controles de acceso específicos.

Cualquier dato incluido en JavaScript entregado al navegador debe considerarse accesible al usuario. Minificar u ofuscar no convierte una credencial en secreta.

16.8. Dependencias

Las aplicaciones actuales reutilizan gran cantidad de software de terceros. Esta práctica acelera desarrollo, pero introduce riesgo de cadena de suministro. Deben conocerse las dependencias directas y transitivas, mantener versiones soportadas, revisar avisos de seguridad y eliminar paquetes innecesarios.

16.9. Rendimiento

El rendimiento web depende de red, latencia, servidor, tamaño de recursos, JavaScript, imágenes, caché y trabajo de renderizado. Optimizar un solo componente sin medir puede desplazar el cuello de botella.

Entre las estrategias habituales están reducir transferencias innecesarias, comprimir representaciones cuando proceda, utilizar formatos adecuados, aplicar caché, optimizar consultas, evitar trabajo JavaScript excesivo y acercar contenido estático mediante CDN.

16.10. Compresión

HTTP permite negociar codificaciones de contenido. La compresión reduce bytes transmitidos, pero consume CPU y no resulta igual de eficaz para todos los formatos. Muchos formatos multimedia ya incorporan compresión propia.

16.11. Observabilidad

Operar servicios exige métricas, registros y trazas. Deben poder medirse latencia, tasa de errores, saturación y disponibilidad. Las alertas se diseñan a partir del impacto sobre el servicio, no únicamente del consumo de CPU.

Los logs deben protegerse porque pueden incluir identificadores, rutas y contexto de operaciones. En sanidad se necesita especial disciplina para evitar registrar datos personales innecesarios.

16.12. Despliegue y continuidad

La actualización de una aplicación debe permitir volver a una versión estable cuando un despliegue falla. Las bases de datos requieren migraciones compatibles. En servicios críticos se emplean estrategias que reduzcan indisponibilidad y faciliten validar la versión nueva antes de exponerla completamente.

La continuidad no es solo redundancia técnica. Deben existir copias verificadas, procedimientos de restauración, monitorización, capacidad suficiente y responsables que sepan actuar durante una incidencia.

17. APLICACIÓN AL SAS Y CLAVES DE EXAMEN

17.1. Aplicaciones web en un entorno sanitario público

Las tecnologías estudiadas forman la base de numerosos servicios corporativos. Un profesional puede utilizar una interfaz HTML y JavaScript que accede mediante HTTPS a servicios backend. Esos servicios pueden consultar sistemas corporativos, directorios, bases de datos y componentes de interoperabilidad. La arquitectura final es distribuida aunque el usuario perciba una única aplicación.

El técnico debe ser capaz de distinguir el problema de cada capa. Un error de renderizado pertenece al frontend; una respuesta 401 puede estar relacionada con autenticación; un 403 con autorización; un 502 puede indicar un problema entre una pasarela y un backend; un tiempo de espera puede proceder de un servicio remoto o de una base de datos. Esta separación permite diagnosticar con método.

17.2. Protección del dato sanitario

Las aplicaciones sanitarias procesan información de especial sensibilidad. El cliente no debe recibir datos que no necesita. El servidor aplica autorización a cada recurso. Las respuestas con información personal deben definir adecuadamente sus políticas de caché. Las trazas y logs se diseñan para diagnosticar sin replicar indiscriminadamente datos clínicos.

TLS protege información durante el tránsito. Autenticación identifica al usuario. Autorización limita las acciones. Auditoría registra las operaciones relevantes. Son funciones complementarias.

17.3. Publicación institucional

Los portales públicos necesitan un gobierno editorial claro. El CMS debe facilitar responsabilidades, revisión, versionado y caducidad. Un contenido sanitario incorrecto o desactualizado puede tener consecuencias mayores que un error de presentación.

Los mecanismos WYSIWYG facilitan edición, pero la calidad final depende de modelos de contenido, política editorial, accesibilidad, revisión y mantenimiento. Un editor visual por sí solo no constituye una estrategia de publicación.

17.4. Interoperabilidad

XML continúa siendo relevante en integraciones sanitarias y administrativas. JSON se utiliza ampliamente en APIs actuales. Elegir un formato común resuelve interoperabilidad sintáctica, pero no garantiza interoperabilidad semántica. Los sistemas deben compartir también significado, identificadores y reglas.

La Web semántica ilustra esa diferencia. RDF expresa relaciones; RDFS y OWL formalizan vocabularios y conocimiento; SPARQL consulta los grafos. Estas tecnologías no sustituyen los estándares clínicos específicos, pero ayudan a comprender qué significa representar conocimiento de forma interpretable por máquinas.

17.5. Preguntas históricas del SAS que debes dominar

• HTML y XML: ambos son lenguajes de marcado, aunque con objetivos diferentes.
• Formularios HTML: select es un elemento, no un tipo de input.
• XML: diferencia entre bien formado y válido y necesidad de anidamiento correcto.
• HTML: respetar el modelo de contenido y la semántica de cada elemento.
• CMS: distinguir una plataforma de gestión de contenidos de un simple editor.
• WYSIWYG: “What You See Is What You Get”.
• Web semántica: RDF como modelo de triples; OWL para ontologías; SPARQL para consulta.
• HTTP: distinguir método, código de estado, representación y versión del protocolo.
• AJAX: técnica asíncrona, no obligación de utilizar XML.
• Cliente frente a servidor: la seguridad no puede confiar en validaciones del navegador.

17.6. Mapa conceptual final