10 Jun

Por profesor
En Informática
Comentarios Ninguno

Conceptos Esenciales en Informática y Desarrollo Web

Mayo 2022/2023

1. Convergencia de Servicios de Telecomunicación en Internet

Pregunta: Explique brevemente qué es la convergencia de servicios de telecomunicación en Internet.

Respuesta: La popularidad y el uso masivo de Internet han impulsado la convergencia de numerosos servicios (televisión, telefonía, acceso a Internet). Esto implica que se puede acceder a estos servicios desde una única infraestructura tecnológica.

2. Diferencias Fundamentales entre HTTP/1.1 y HTTP/2

Pregunta: Exponga y comente brevemente una diferencia fundamental entre las versiones HTTP/1.1 y HTTP/2.

Respuesta: HTTP/1.1 presenta ineficiencias significativas, como cabeceras extensas y repetitivas, y un procesamiento secuencial de las peticiones, lo que introduce latencia en la comunicación. HTTP/2 aborda estas limitaciones mejorando el rendimiento mediante la optimización de cabeceras, el multiplexado de peticiones y respuestas sobre una única conexión TCP (utilizando ‘streams’), y la priorización de peticiones para un procesamiento más eficiente. Nota: HTTP es un protocolo de intercambio de información que utiliza URIs para identificar recursos de manera unívoca.

3. Ventaja de Servicios Web REST sobre SOAP

Pregunta: Exponga una ventaja de los servicios web REST con respecto a los servicios web SOAP.

Respuesta: Una ventaja fundamental de los servicios web REST es su reutilización de protocolos existentes como HTTP para sus peticiones, empleando las operaciones CRUD (Create, Read, Update, Delete) y localizando recursos mediante URIs, lo que los hace más intuitivos. Además, REST no impone un formato de datos específico, permitiendo el uso de opciones más ligeras como JSON, que es más fácil de procesar. En contraste, SOAP se basa en XML, lo que lo hace más verboso y pesado. Nota: SOAP es un protocolo basado en XML, lo que puede generar redundancia, mientras que REST utiliza métodos HTTP y manipula objetos a través de URIs.

4. Diferencia entre Página Web Estática y Dinámica

Pregunta: Explique cuál es la diferencia fundamental entre una página web estática y una página web dinámica.

Respuesta: Una página web estática se almacena en un servidor remoto y no varía su contenido para cada usuario. Por el contrario, una página web dinámica se genera bajo demanda del servidor, adaptando su contenido. La tecnología principal utilizada para personalizar la información según los gustos del usuario son las cookies.

5. Patrones de Modelado en Bases de Datos MongoDB

Pregunta: ¿Qué dos patrones de modelado se pueden emplear en las bases de datos MongoDB?

Respuesta: Los dos patrones de modelado principales en MongoDB son embeber (embedding) y referenciar (referencing):

Embeber: Consiste en incrustar documentos relacionados directamente dentro de otros, haciéndolos parte del mismo documento. Es útil para relaciones uno a uno o uno a pocos, donde los datos están estrechamente acoplados.
Referenciar: Implica que un documento incluye referencias (normalmente el _id) a otros documentos. Este patrón es preferible para relaciones de uno a muchos o de muchos a muchos, donde los datos pueden estar más desacoplados o ser muy grandes.

6. Documentos XML: Bien Formado y Válido

Pregunta: En un documento XML, ¿qué significa que está bien formado? ¿Y qué significa que es válido?

Respuesta: En un documento XML:

Un documento está bien formado si cumple con las reglas sintácticas básicas de XML (por ejemplo, todas las etiquetas están cerradas, los atributos están entre comillas, etc.).
Un documento es válido si, además de estar bien formado, cumple con las reglas definidas en su DTD (Document Type Definition) o en un esquema XML (como XML Schema).

7. Acciones HTML para una Página Web más Accesible

Pregunta: Enumere y justifique brevemente, tres acciones en el código HTML que deberían llevarse a cabo para conseguir una página web más accesible.

Respuesta: Para mejorar la accesibilidad de una página web, se pueden llevar a cabo las siguientes acciones en el código HTML:

Emplear elementos semánticos apropiados: Utilizar etiquetas HTML como <header>, <nav>, <main>, <article>, <section>, <footer>, etc., en lugar de <div> genéricos. Esto facilita la comprensión de la estructura del contenido por parte de los lectores de pantalla, mejora el desarrollo (especialmente en dispositivos móviles) y es beneficioso para el SEO.
Adecuar el contenido textual: Incluir atributos alt descriptivos en las imágenes (<img>), proporcionar transcripciones para contenido multimedia, y asegurar que el texto sea legible y contrastado. Esto permite que usuarios con discapacidades visuales o auditivas accedan a la información.
Permitir la accesibilidad desde el teclado: Asegurar que todos los elementos interactivos (enlaces, botones, formularios) sean navegables y activables mediante el teclado (usando la tecla Tab, Enter, etc.). Esto es crucial para usuarios que no pueden usar un ratón, garantizando que tengan las mismas oportunidades de interacción.

8. Solución a la Política de Restricción de Acceso al Mismo Origen (CORS)

Pregunta: ¿Cómo se puede solucionar la política de restricción de acceso al mismo origen que emplean los navegadores?

Respuesta: La política de restricción de acceso al mismo origen (Same-Origin Policy) de los navegadores se puede solucionar implementando la configuración de CORS (Cross-Origin Resource Sharing) en el servidor. Por defecto, los navegadores impiden que un script realice peticiones a un origen diferente al de la página que lo cargó. Mediante CORS, el servidor puede especificar qué orígenes (dominios, puertos, protocolos) tienen permiso para acceder a sus recursos, o incluso permitir el acceso desde cualquier origen utilizando un asterisco (*).

9. Almacenamiento de Información de Estado con HTTP (Cookies)

Pregunta: ¿Qué forma proporciona HTTP para que se pueda almacenar información de estado dependiente del dominio al que se accede en el navegador?

Respuesta: HTTP proporciona las cookies como mecanismo para almacenar información de estado persistente y dependiente del dominio en el navegador del usuario. Las cookies son pequeños fragmentos de datos que el servidor envía al navegador, y este los almacena y los devuelve en futuras peticiones al mismo dominio. Se utilizan para recordar información como preferencias del usuario, estado de sesión, o datos de seguimiento, permitiendo que el contenido de la página se adapte a los intereses del usuario.

10. JSX en React.js

Pregunta: ¿Qué es JSX en el contexto de React.js? Ponga un ejemplo sencillo de empleo de JSX para un párrafo con inserción del valor de una variable.

Respuesta: En el contexto de React.js, JSX (JavaScript XML) es una extensión de sintaxis que permite escribir código similar a HTML dentro de archivos JavaScript. Facilita la creación de elementos de interfaz de usuario de React, haciendo el código más legible y comprensible.

Ejemplo sencillo de JSX con inserción de una variable:

function App() {
  const message = "Este es un mensaje desde una variable.";
  return (
    <div>
      <p>{message}</p>
    </div>
  );
}

Mayo 2021/2022

1. Definición de Servicio de Telecomunicación

Pregunta: Defina qué es un servicio de telecomunicación.

Respuesta: Un servicio de telecomunicación es un conjunto de medios y recursos gestionados por un proveedor con el fin de satisfacer las necesidades de comunicación de un usuario, permitiendo el intercambio de información a distancia.

2. Elementos de una Petición HTTP/1.1

Pregunta: Enumere los elementos de una petición HTTP/1.1. Ponga un ejemplo ilustrativo de una petición para obtener un recurso de un servidor HTTP/1.1.

Respuesta: Los elementos principales de una petición HTTP/1.1 son:

Línea de solicitud: Contiene el método HTTP (GET, POST, etc.), la ruta del recurso y la versión del protocolo.
Cabeceras (Headers): Pares clave-valor que proporcionan información adicional sobre la petición, el cliente o el recurso. En HTTP/1.1, la cabecera Host es obligatoria.
Línea en blanco: Separa las cabeceras del cuerpo del mensaje.
Cuerpo del mensaje (opcional): Contiene los datos enviados con la petición (por ejemplo, en una petición POST).

Ejemplo ilustrativo de una petición GET en HTTP/1.1:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

3. Ventaja de Servicios Web SOAP sobre REST

Pregunta: Exponga una ventaja de los servicios web SOAP con respecto a los servicios REST.

Respuesta: Una ventaja de los servicios web SOAP con respecto a REST es su robustez y seguridad inherente, lo que los hace preferibles en entornos empresariales o APIs privadas donde la fiabilidad y la seguridad son críticas. SOAP ofrece características integradas para la seguridad (WS-Security), transacciones (WS-AtomicTransaction) y fiabilidad de mensajes (WS-ReliableMessaging), que no están directamente presentes en REST y deben implementarse de forma adicional.

4. Diferencia Fundamental entre Página Web Estática y Dinámica

Pregunta: Explique cuál es la diferencia fundamental entre una página web estática y una página web dinámica.

Respuesta: La diferencia fundamental radica en cómo se genera y presenta el contenido:

Una página web estática es un archivo predefinido almacenado en un servidor. Su contenido no cambia en función de las interacciones o preferencias del usuario, siendo idéntico para todos los visitantes. Actualizar una página estática con grandes volúmenes de contenido puede ser tedioso.
Una página web dinámica genera su contenido en tiempo real, adaptándose a las preferencias, interacciones o datos específicos del usuario. El contenido puede variar con cada solicitud. Para conocer estas preferencias, se hace uso de tecnologías como las cookies.

5. Extensibilidad y Portabilidad de un Documento XML

Pregunta: ¿Qué implican las características de extensibilidad y portabilidad de un documento XML?

Respuesta: En un documento XML:

La extensibilidad implica que las aplicaciones pueden seguir procesando un documento XML incluso si se le añaden nuevos elementos o atributos que no estaban previstos originalmente en su definición. Esto permite la evolución de los formatos de datos sin romper la compatibilidad con versiones anteriores.
La portabilidad se refiere a la capacidad de XML para definir información en texto plano, lo que lo hace independiente de la plataforma de hardware o software. Un documento XML puede ser creado y leído en cualquier sistema que soporte el estándar XML, facilitando el intercambio de datos entre diferentes entornos.

6. Interfaces del Objeto Window (Screen, Location, History, Navigator)

Pregunta: ¿Qué información permiten conseguir las interfaces Screen, Location, History y Navigator del objeto Window?

Respuesta: Las interfaces Screen, Location, History y Navigator del objeto Window en JavaScript proporcionan acceso a la siguiente información:

Screen: Ofrece información sobre la pantalla del usuario, como su anchura (screen.width), altura (screen.height), profundidad de color (screen.colorDepth), etc.
Location: Proporciona detalles sobre la URL actual de la página cargada en la ventana, incluyendo propiedades como href (URL completa), hostname (nombre de host), pathname (ruta del archivo), protocol (protocolo), entre otros.
History: Permite interactuar con el historial de navegación del navegador para la ventana actual, con métodos como back() (volver a la página anterior), forward() (ir a la página siguiente) y go() (navegar a una posición específica en el historial).
Navigator: Contiene información sobre el navegador web del usuario, como el nombre de la aplicación (navigator.appName), el código del nombre de la aplicación (navigator.appCodeName), la plataforma (navigator.platform), el agente de usuario (navigator.userAgent), etc.

7. Problemas de Conexiones Síncronas con XMLHttpRequest()

Pregunta: ¿Qué problema presentaría en una página web con diferentes operaciones disponibles al usuario si una operación se implementará con una conexión síncronas con XMLHttpRequest()? ¿Cómo se podría solucionar?

Respuesta: Si una operación en una página web se implementara con una conexión síncrona utilizando XMLHttpRequest(), el problema principal sería que el navegador bloquearía el hilo principal de JavaScript hasta que la petición se complete. Esto significa que la interfaz de usuario se congelaría, impidiendo cualquier interacción del usuario (clics, escritura, desplazamiento) mientras se espera la respuesta del servidor. Esto resulta en una experiencia de usuario deficiente, especialmente si las peticiones tardan en completarse.

La solución a este problema es el uso de conexiones asíncronas. Al realizar peticiones de forma asíncrona, el hilo principal de JavaScript no se bloquea, permitiendo que la página siga siendo interactiva mientras la petición se procesa en segundo plano. Esto se puede lograr utilizando XMLHttpRequest de forma asíncrona (su comportamiento por defecto), o más modernamente, con la API Fetch y las palabras clave async/await para manejar las solicitudes de manera más legible y eficiente.

8. Acceso a Recursos Fuera del Servidor (CORS)

Pregunta: ¿Qué sucede cuando un script de una página intenta acceder a un recurso fuera del servidor desde el que se descargó dicha página? ¿Cómo se podría solucionar?

Respuesta: Cuando un script de una página intenta acceder a un recurso ubicado en un servidor con un origen diferente (dominio, protocolo o puerto) al de la página que lo cargó, el navegador aplica la Política de Mismo Origen (Same-Origin Policy). Por defecto, esta política denegará el acceso a dicho recurso por motivos de seguridad, a menos que el servidor de destino lo permita explícitamente.

La solución a este problema es la implementación de CORS (Cross-Origin Resource Sharing) en el servidor que aloja el recurso. Para permitir el acceso, el servidor debe incluir cabeceras HTTP específicas en sus respuestas, como Access-Control-Allow-Origin (especificando el origen permitido o * para todos), Access-Control-Allow-Methods (métodos HTTP permitidos) y Access-Control-Allow-Headers (cabeceras permitidas). Además, para ciertas peticiones (como las que usan métodos HTTP distintos de GET/POST simples o cabeceras personalizadas), el navegador realiza una petición «preflight» (con el método OPTIONS) para verificar los permisos antes de enviar la petición real.

Ejemplo de configuración en un servidor Node.js con Express:

app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'http://tu-dominio.com'); // O '*' para permitir todos
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  next();
});

9. Arquitectura MVC y Clasificación de Tecnologías

Pregunta: Exponga brevemente las funciones de cada parte de la arquitectura MVC. Si tuviera que clasificar las siguientes tecnologías en solamente una parte ¿cuál sería?: MongoDB, CSS, Node.js, PUG, Mustache, HTML, PHP.

Respuesta: La arquitectura MVC (Modelo-Vista-Controlador) es un patrón de diseño que separa la lógica de una aplicación en tres componentes interconectados para mejorar la modularidad y la mantenibilidad:

Modelo: Representa la lógica de negocio y los datos de la aplicación. Se encarga de la gestión de los datos, su almacenamiento, recuperación y manipulación. Interactúa directamente con la base de datos.
Vista: Es la interfaz de usuario. Se encarga de presentar los datos al usuario de la forma adecuada y de recibir sus interacciones. No contiene lógica de negocio.
Controlador: Actúa como intermediario entre el Modelo y la Vista. Recibe las peticiones del usuario (desde la Vista), las procesa, interactúa con el Modelo para obtener o actualizar datos, y luego selecciona la Vista apropiada para mostrar la respuesta al usuario.

Clasificación de tecnologías en MVC:

Modelo: MongoDB (base de datos NoSQL), SQL (lenguaje de consulta para bases de datos relacionales, aquí representando la capa de datos)
Vista: CSS, HTML, PUG (motor de plantillas), Mustache (motor de plantillas)
Controlador: Node.js (entorno de ejecución JavaScript del lado del servidor), PHP (lenguaje de programación del lado del servidor)

10. JSX en React.js (Duplicado)

Pregunta: ¿Qué es JSX en el contexto de React.js? Ponga un ejemplo sencillo de empleo de JSX con inserción del valor de una variable.

Ejemplo sencillo de JSX con inserción de una variable:

function App() {
  const message = "Este es un mensaje de ejemplo.";
  return (
    <div>
      <p>{message}</p>
    </div>
  );
}

Mayo 2020/2021

1. Funciones de la Capa de Aplicación TCP/IP vs. OSI

Pregunta: Dentro del modelo de referencia TCP/IP, si se compara con el modelo de referencia OSI ¿qué funciones recaería sobre la capa de aplicación del primero si se quisiera ofrecer un nivel de servicio equivalente?

Respuesta: En el modelo de referencia TCP/IP, para ofrecer un nivel de servicio equivalente al modelo OSI, la capa de aplicación de TCP/IP debería asumir las funciones de las capas de sesión y presentación del modelo OSI. Esto incluye servicios para establecer, gestionar y terminar sesiones de comunicación, así como para traducir, cifrar/descifrar y comprimir/descomprimir los datos.

2. Internet Engineering Task Force (IETF)

Pregunta: Responda de manera breve y precisa a las siguientes cuestiones sobre la Internet Engineering Task Force o IETF:

¿Cuál es su función principal?
¿Cómo se denominan los documentos más importantes que publica este organismo?
¿Cuál es la función principal de estos documentos?
¿Cuáles son las categorías actuales de estos tipos de documentos?

Respuesta: Sobre la Internet Engineering Task Force (IETF):

Función principal: Es el principal organismo encargado del desarrollo y la evolución de la arquitectura de Internet y sus protocolos, centrándose en la ingeniería y el funcionamiento de la red.
Documentos más importantes: Se denominan RFC (Request for Comments).
Función principal de los RFC: Documentan especificaciones técnicas, estándares, protocolos, métodos y comportamientos relacionados con Internet. Sirven como la principal fuente de información técnica para la comunidad de Internet.
Categorías actuales de RFC (según madurez técnica):
- Estándares Oficiales:
  - Proposed Standard: Propuestas de estándares que están en revisión.
  - Internet Standard: Estándares maduros y ampliamente adoptados.
- No Estándares:
  - Históricos: Estándares obsoletos o reemplazados.
  - Informativos: Documentos que proporcionan información general o tutoriales.
  - Experimentales: Documentos que describen trabajos en curso o ideas experimentales.

3. Elementos de Petición y Respuesta HTTP/1.1

Pregunta: Enumere los elementos de una petición y una respuesta HTTP. Ponga un ejemplo ilustrativo de ambos para la versión HTTP/1.1.

Respuesta: Los elementos de una petición y una respuesta HTTP/1.1 son:

Petición HTTP/1.1:

Línea de solicitud: Método SP Ruta SP Versión_HTTP (Ej: GET /index.html HTTP/1.1)
Cabeceras (Headers): Pares Clave: Valor que proporcionan metadatos sobre la petición (generales, de petición, de entidad).
Línea en blanco: Separa las cabeceras del cuerpo.
Cuerpo del mensaje (opcional): Contiene los datos de la petición (ej: datos de formulario en POST).

Ejemplo de Petición HTTP/1.1:

GET /index.html HTTP/1.1
Host: www.ujaen.es
User-Agent: Chrome/125.0.0.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: es-ES,es;q=0.8,en-US;q=0.5,en;q=0.3
Connection: keep-alive

Respuesta HTTP/1.1:

Línea de estado: Versión_HTTP SP Código_Estado SP Descripción_Estado (Ej: HTTP/1.1 200 OK)
Cabeceras de respuesta: Pares Clave: Valor que proporcionan metadatos sobre la respuesta (generales, de respuesta, de entidad).
Línea en blanco: Separa las cabeceras del cuerpo.
Cuerpo del mensaje (opcional): Contiene el recurso solicitado (ej: el contenido HTML de la página).

Ejemplo de Respuesta HTTP/1.1:

HTTP/1.1 200 OK
Date: Mon, 27 May 2024 10:30:00 GMT
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 300
Content-Type: text/html; charset=UTF-8
Connection: keep-alive

4. Desventaja de Servicios Web SOAP sobre REST

Pregunta: Comente una desventaja de los servicios web SOAP con respecto a los servicios REST.

Respuesta: Una desventaja significativa de los servicios web SOAP en comparación con REST es su mayor complejidad y verbosidad. SOAP es un protocolo que se basa exclusivamente en XML para la estructura de sus mensajes, lo que resulta en payloads más grandes y, a menudo, redundantes. En contraste, REST es un estilo arquitectónico que puede utilizar formatos de datos más ligeros y eficientes como JSON, que es más fácil de procesar y más legible para los humanos. Además, REST aprovecha los métodos HTTP estándar (GET, POST, PUT, DELETE) y la identificación de recursos mediante URIs, lo que simplifica su diseño y uso.

5. Definición y Representación del DOM (Document Object Model)

Pregunta: Defina qué es el DOM (Document Object Model) y cómo se representa.

Respuesta: El DOM (Document Object Model) es una interfaz de programación para documentos HTML, XML y SVG. Representa la estructura de un documento como un árbol de objetos, donde cada nodo del árbol corresponde a una parte del documento (elementos, atributos, texto, etc.). Permite que los programas (como JavaScript) accedan y manipulen el contenido, la estructura y el estilo de los documentos web. Se representa conceptualmente como una estructura jerárquica en forma de árbol.

6. Scripts Asíncronos vs. Diferidos

Pregunta: ¿Qué diferencia fundamental existe entre los scripts cargados de manera asíncrona a la página web y los diferidos? ¿Por qué necesitaría definir un tipo u otro en una página web?

Respuesta: La diferencia fundamental entre los scripts cargados de manera asíncrona (async) y los diferidos (defer) en una página web radica en el momento de su ejecución y su impacto en el renderizado del HTML:

Scripts Asíncronos (<script async>): No bloquean el parseo del HTML ni la carga de otros scripts. Se descargan en paralelo con el HTML y se ejecutan tan pronto como están disponibles, incluso si el HTML aún no ha terminado de parsearse. Esto puede causar problemas si el script tiene dependencias con otros scripts o con elementos del DOM que aún no se han cargado.
Scripts Diferidos (<script defer>): También se descargan en paralelo con el HTML y no bloquean el parseo. Sin embargo, su ejecución se pospone hasta que el HTML ha sido completamente parseado y el DOM está listo, pero antes de que se dispare el evento DOMContentLoaded. Los scripts defer se ejecutan en el orden en que aparecen en el HTML.

¿Por qué necesitaría definir un tipo u otro?

Se usaría async para scripts independientes que no tienen dependencias con el DOM o con otros scripts, y que pueden ejecutarse en cualquier momento sin afectar la funcionalidad principal de la página (ej., scripts de analíticas, anuncios).
Se usaría defer para scripts que dependen del DOM o de otros scripts, pero que no son críticos para el renderizado inicial de la página. Permite que el HTML se muestre rápidamente mientras los scripts se cargan en segundo plano y se ejecutan en el orden correcto una vez que el DOM está listo, mejorando la experiencia de usuario y el rendimiento.

7. Problemas de Conexiones Síncronas con XMLHttpRequest() (Duplicado)

8. Necesidad y Configuración de CORS

Pregunta: Comente brevemente qué provoca la necesidad de activar el Intercambio de Recursos de Origen Cruzado (CORS). ¿En qué extremo de la comunicación con HTTP se debe configurar el CORS? ¿Por qué?

Respuesta: La necesidad de activar el Intercambio de Recursos de Origen Cruzado (CORS) surge debido a la Política de Mismo Origen (Same-Origin Policy) implementada por los navegadores web. Esta política de seguridad restringe que un documento o script cargado desde un origen (dominio, protocolo o puerto) pueda interactuar con recursos de otro origen. Si un script intenta acceder a un recurso externo sin la configuración CORS adecuada, el navegador bloqueará la petición para prevenir posibles ataques como el Cross-Site Request Forgery (CSRF) o la fuga de datos.

CORS debe configurarse en el extremo del servidor que aloja los recursos a los que se desea permitir el acceso desde otros orígenes. Esto se debe a que es el servidor quien posee los datos y es responsable de decidir qué orígenes externos tienen permiso para acceder a ellos. Al configurar CORS en el servidor, se añaden cabeceras HTTP específicas a las respuestas que indican al navegador si el origen de la petición está permitido, proporcionando un control granular sobre la seguridad de los datos sin requerir cambios en el código del cliente.

9. Arquitectura MVC y Clasificación de Tecnologías (Duplicado)

Modelo: Representa la lógica de negocio y los datos de la aplicación. Se encarga de la gestión de los datos, su almacenamiento, recuperación y manipulación. Interactúa directamente con la base de datos.
Vista: Es la interfaz de usuario. Se encarga de presentar los datos al usuario de la forma adecuada y de recibir sus interacciones. No contiene lógica de negocio.
Controlador: Actúa como intermediario entre el Modelo y la Vista. Recibe las peticiones del usuario (desde la Vista), las procesa, interactúa con el Modelo para obtener o actualizar datos, y luego selecciona la Vista apropiada para mostrar la respuesta al usuario.

Clasificación de tecnologías en MVC:

Modelo: MongoDB (base de datos NoSQL), SQL (lenguaje de consulta para bases de datos relacionales, aquí representando la capa de datos)
Vista: CSS, HTML, PUG (motor de plantillas), Mustache (motor de plantillas)
Controlador: Node.js (entorno de ejecución JavaScript del lado del servidor), PHP (lenguaje de programación del lado del servidor)

10. Métodos componentDidMount() y componentDidUpdate() en React.js

Pregunta: Comente brevemente qué son y qué función tienen los métodos componentDidMount() y componentDidUpdate() en un componente React.js.

Respuesta: En un componente de clase de React.js, componentDidMount() y componentDidUpdate() son métodos del ciclo de vida:

componentDidMount(): Este método se invoca inmediatamente después de que un componente ha sido montado (es decir, insertado en el árbol del DOM). Es un lugar ideal para realizar inicializaciones que requieren el DOM, como peticiones de red para cargar datos, suscripciones a eventos del DOM, o la integración con librerías de terceros.
componentDidUpdate(prevProps, prevState): Este método se invoca inmediatamente después de que un componente se ha actualizado (es decir, ha recibido nuevas propiedades (props) o ha cambiado su estado (state)). Es el lugar adecuado para realizar operaciones que necesitan ejecutarse después de que el componente se haya vuelto a renderizar debido a un cambio, como realizar peticiones de red basadas en cambios de props, o actualizar el DOM en respuesta a interacciones del usuario.

Preguntas Varias sobre Desarrollo Web y Redes

Gestión de Peticiones CORS Verificadas

Pregunta: Describa cómo se gestiona una petición CORS verificada. ¿Cuándo se envían estas peticiones?

Respuesta: Una petición CORS verificada se gestiona mediante un intercambio entre el navegador y el servidor. Cuando un script intenta realizar una petición cross-origin que no es una ‘petición simple’ (ej., métodos PUT/DELETE, cabeceras personalizadas, Content-Type distinto de application/x-www-form-urlencoded, multipart/form-data, o text/plain), el navegador envía primero una petición ‘preflight’ utilizando el método OPTIONS. Esta petición OPTIONS incluye cabeceras como Access-Control-Request-Method y Access-Control-Request-Headers, informando al servidor sobre la petición real que se pretende realizar.

Si el servidor responde a la petición OPTIONS con las cabeceras Access-Control-Allow-Origin, Access-Control-Allow-Methods y Access-Control-Allow-Headers adecuadas, indicando que el origen y los métodos/cabeceras solicitados están permitidos, entonces el navegador procede a enviar la petición HTTP real con el método y las cabeceras correctas. Si la respuesta preflight no es satisfactoria, el navegador bloquea la petición real.

Peticiones Fetch() a Dominios Externos

Pregunta: ¿Qué podría suceder si hago una petición Fetch() a un dominio al que no pertenece la página desde donde hago la petición?

Respuesta: Si se realiza una petición Fetch() a un dominio diferente al de la página actual (una petición cross-origin), el navegador aplicará la Política de Mismo Origen.

Si el servidor de destino no tiene configurado CORS para permitir el origen de la página que realiza la petición, el navegador bloqueará la respuesta por motivos de seguridad. La petición se enviará al servidor, y este la procesará, pero el navegador no permitirá que el script acceda a la respuesta, resultando en un error de CORS en la consola del desarrollador.
Si el servidor de destino tiene configurado CORS correctamente y permite el origen de la página, el navegador permitirá que la petición se envíe y que el script acceda a la respuesta, gestionando cualquier petición ‘preflight’ si es necesario.

Comportamiento de Recursos en Node.js con Métodos HTTP y Aporte de Express

Pregunta: ¿Es posible que un mismo recurso implementado en Node.js tenga comportamientos diferentes para cada método HTTP? ¿Qué aporta Express a Node.js?

Respuesta: Sí, es completamente posible y es una práctica común que un mismo recurso implementado en Node.js tenga comportamientos diferentes para cada método HTTP (GET, POST, PUT, DELETE, etc.). Esto es fundamental para construir APIs RESTful, donde el método HTTP indica la acción que se desea realizar sobre un recurso (ej., GET para obtener, POST para crear, PUT para actualizar, DELETE para eliminar).

Express.js es un framework de aplicaciones web para Node.js que simplifica enormemente el manejo de rutas y métodos HTTP. Aporta a Node.js una capa de abstracción que facilita la definición de endpoints y la asignación de funciones controladoras a métodos HTTP específicos para una URL determinada. Esto permite que un desarrollador defina de manera clara y eficiente cómo un recurso debe responder a cada tipo de petición HTTP, mejorando la organización del código y la productividad.

Validación de Documentos XML

Pregunta: ¿Cuándo se quiere validar un XML? Comente brevemente qué es necesario y qué debe cumplirse.

Respuesta: Se desea validar un documento XML cuando, además de asegurar que su sintaxis es correcta (que está ‘bien formado’), se necesita verificar que su estructura y contenido cumplen con un conjunto predefinido de reglas.

Para que un documento XML sea válido, es necesario que:

Esté bien formado: Cumpla con las reglas sintácticas fundamentales de XML (ej., etiquetas correctamente anidadas y cerradas, atributos entre comillas, un único elemento raíz).
Cumpla con las reglas definidas en su DTD (Document Type Definition) o en un esquema XML (como XML Schema, Relax NG, Schematron): Estas definiciones especifican la estructura permitida del documento, los elementos y atributos que puede contener, su orden, sus tipos de datos, y sus relaciones. La validación asegura que el documento se ajusta a un modelo de datos específico.

Causas de Recursos Vinculados que Afectan el Rendimiento Web

Pregunta: Comente 2 causas de los recursos vinculados a una página web que afectaron a su rendimiento.

Respuesta: Dos causas comunes de recursos vinculados a una página web que afectan negativamente su rendimiento son:

Falta de uso de CDN (Content Delivery Network): Si los recursos estáticos (imágenes, CSS, JavaScript) no se sirven desde una CDN, se cargarán directamente desde el servidor de origen. Esto puede aumentar la latencia para usuarios geográficamente distantes, ya que los datos deben viajar una mayor distancia, resultando en tiempos de carga más lentos. Una CDN distribuye copias de los recursos en servidores ubicados estratégicamente en todo el mundo, permitiendo que los usuarios los descarguen desde el servidor más cercano.
Excesivas redirecciones HTTP: Cada redirección (ej., de http a https, o de www.dominio.com a dominio.com) implica una solicitud HTTP adicional al servidor. Múltiples redirecciones en cadena pueden añadir una latencia significativa al tiempo de carga de la página, ya que el navegador debe realizar varias idas y venidas al servidor antes de poder acceder al recurso final.

Otras causas relevantes incluyen:

Recursos no optimizados: Imágenes de gran tamaño sin comprimir, archivos CSS/JS no minificados o sin concatenar.
Bloqueo de renderizado: Scripts o hojas de estilo que bloquean el renderizado inicial de la página.
Peticiones a terceros: Demasiadas peticiones a servicios externos (anuncios, trackers) que pueden ser lentos o fallar.
Uso de protocolos ineficientes: Por ejemplo, seguir utilizando HTTP/1.1 en lugar de HTTP/2 o HTTP/3, que ofrecen mejoras significativas en el rendimiento (multiplexado, compresión de cabeceras).

Diferencia Fundamental entre TCP/IP y OSI

Pregunta: Diferencia fundamental entre TCP/IP y OSI. ¿Es posible suplir las diferencias en la capa de aplicación de TCP/IP?

Respuesta: La diferencia fundamental entre el modelo TCP/IP y el modelo OSI radica en su estructura de capas. Mientras que el modelo OSI define siete capas distintas (Física, Enlace de Datos, Red, Transporte, Sesión, Presentación y Aplicación), el modelo TCP/IP originalmente definía cuatro (Acceso a la Red, Internet, Transporte, Aplicación), y en versiones más modernas se suele representar con cinco (Física, Enlace de Datos, Red, Transporte, Aplicación).

La principal distinción es que el modelo TCP/IP no tiene capas separadas para Sesión y Presentación.

Sí, es posible suplir las funciones de las capas de Sesión y Presentación del modelo OSI dentro de la capa de aplicación de TCP/IP. Esto significa que los protocolos de aplicación en TCP/IP (como HTTP, FTP, SMTP) deben incorporar la lógica necesaria para:

Establecer y gestionar sesiones: Controlar el diálogo entre aplicaciones.
Traducir, proteger y comprimir datos: Manejar la representación de los datos, el cifrado/descifrado y la compresión/descompresión.

Documentos RFC de IETF: Nomenclatura y Validez

Pregunta: ¿Cómo se denominan y qué función hacen los documentos más importantes que publica IETF? ¿Son válidas indefinidamente?

Respuesta: Los documentos más importantes que publica la IETF se denominan RFC (Request for Comments). Su función principal es documentar y estandarizar todos los aspectos técnicos relacionados con la arquitectura, protocolos y funcionamiento de Internet. Sirven como la base para la interoperabilidad y el desarrollo de la red.

No, los RFC no son válidos indefinidamente. Su validez puede cambiar con el tiempo. Un RFC puede ser:

Obsoleto: Reemplazado por una versión más reciente o un protocolo superior/más eficiente.
Histórico: Ya no se considera un estándar actual, pero se mantiene por su valor histórico.
Informacional o Experimental: No pretenden ser estándares, sino proporcionar información o describir trabajos en curso.

La IETF revisa y actualiza continuamente los estándares para adaptarse a las nuevas tecnologías y necesidades de Internet.

Conceptos Fundamentales de Redes y Web

Servicio de Telecomunicación

Pregunta: ¿Cuál de las siguientes características NO es propia de un servicio de telecomunicación?

Respuesta: Emplear solamente medios cableados para transmitir la información. (Correcto)

Características Generales de un Servicio de Telecomunicación:

Uno o varios tipos de información a intercambiar.
Un medio o canal para su difusión (no necesariamente solo cableado).
Uno o varios dispositivos transmisores de información.
Uno o varios dispositivos receptores de información.
Uno o varios generadores de información.
Uno o varios consumidores de la información.

Aplicaciones, Protocolos y Modelos de Red (OSI y TCP/IP)

Pregunta: ¿Qué funciones se atribuyen a la capa de aplicación del modelo de referencia TCP/IP que están expresamente diferenciadas en el modelo de referencia OSI?

Respuesta: Aquellas vinculadas a las capas de sesión y presentación del modelo de referencia OSI.

Pregunta: ¿Cuáles son los niveles o capas que define el modelo de referencia OSI, ordenados de mayor proximidad a las características físicas del medio de transmisión a menor?

Respuesta: Física, Enlace de Datos, Red, Transporte, Sesión, Presentación y Aplicación.

Pregunta: ¿Cuáles son los principales componentes funcionales de la World Wide Web?

Respuesta: El lenguaje HTML, el protocolo HTTP y el sistema de direccionamiento basado en URIs.

Pregunta: Identifique qué propiedad NO corresponde con el paradigma cliente-servidor.

Respuesta: Requiere de protocolos orientados a conexión para que el cliente se conecte con el servidor.

Pregunta: ¿Qué definición se correspondería con la de un protocolo de aplicación en Internet?

Respuesta: Son las normas que rigen el intercambio de información entre los procesos que pertenecen a la aplicación.

Paradigmas de Comunicación en Red

Cliente-Servidor

Suele implicar una relación uno (servidor) a muchos (clientes).
Un servicio, normalmente, requiere que el servidor esté continuamente ejecutándose.
Habitualmente, un servicio es ofrecido por una aplicación servidora, pero puede que dicha aplicación ofrezca varios servicios diferentes.
También es posible que para ofrecer un servicio adecuadamente sean necesarios varios servidores.

Entre Pares o Peer-to-Peer (P2P)

Todos los participantes ofrecen y demandan el servicio.
Se comportan como clientes y servidores de manera simultánea.

World Wide Web (WWW)

Utiliza el protocolo HTTP.
Es el servicio por excelencia para el acceso a la información para la mayoría de usuarios de Internet.
En la actualidad, multitud de servicios se ofrecen a través de la web, lo que se conoce como Web 2.0.
Su origen se encuentra en el concepto de hipertexto: una forma de enlazar documentos y transferirlos.
Conjuntamente con el éxito de TCP/IP, la web ha evolucionado hasta lo que es hoy en día.

Modelo OSI: Capas y Funciones

Capa 7 – Aplicación: Permite el acceso a los recursos de la red.
Capa 6 – Presentación: Traduce, cifra y comprime los datos.
Capa 5 – Sesión: Establece, gestiona y termina sesiones de comunicación.
Capa 4 – Transporte: Proporciona una forma confiable de comunicación entre procesos, así como la recuperación de errores.
Capa 3 – Red: Mueve los paquetes desde su origen a su destino, proporcionando un servicio de conexionado virtual entre redes.
Capa 2 – Enlace de Datos: Organiza los bits en tramas para proporcionar una distribución de los datos tramo a tramo (salto a salto).
Capa 1 – Física: Transmite los bits sobre un medio y proporciona las especificaciones mecánicas y eléctricas para poder hacerlo.

Modelo TCP/IP

La suite de protocolos TCP/IP fue desarrollada antes de la aparición del modelo OSI, por lo que no coincide exactamente con su estructura.
Originalmente, tenía cuatro niveles, pero actualmente se suelen definir cinco capas.
No incluye capas separadas de sesión y presentación; sus funciones se incorporan a la capa de aplicación.

Estructura Administrativa de Internet

Pregunta: ¿Qué organismo se encarga, entre otros aspectos, de desarrollar los estándares que se podrán emplear en Internet?

Respuesta: IETF (Internet Engineering Task Force).

Pregunta: ¿Qué tipo de documentos RFC definen en la actualidad los estándares en Internet gestionados por el IETF?

Respuesta: Los documentos RFC que marcan los estándares de Internet se catalogan como «Proposed Standard» o «Internet Standard». (Correcto)

IETF (Internet Engineering Task Force)

Organismo de gran relevancia para desarrolladores de aplicaciones y la evolución de Internet.
Opera como una comunidad abierta con grupos de trabajo que siguen un proceso de colaboración abierto.
Se encarga del desarrollo de documentos dentro de la arquitectura de Internet, incluyendo:
- Normas y Estándares (RFCs):
  - Proposed Standard
  - Internet Standard
- Según RFC 2026, también se mencionaban:
  - Proposed Standards
  - Draft Standards
  - Internet Standards

Internet Architecture Board (IAB)

La Junta de Arquitectura de Internet (IAB) es un comité responsable del monitoreo y desarrollo de Internet, designado por la Internet Society.

Internet Research Task Force (IRTF)

La Fuerza de Tareas de Investigaciones de Internet (IRTF) es un grupo hermano del IETF. Su principal misión es la investigación a largo plazo en temas relacionados con Internet.

Protocolo HTTP: Evolución y Métodos

Preguntas Clave sobre HTTP

Pregunta: ¿Qué enunciado corresponde con una nueva característica de HTTP/2 frente a HTTP/1.1?
Respuesta: Permite enviar varias peticiones seguidas sin esperar a que estas sean respondidas (multiplexado).
Pregunta: ¿Qué diferencia supone enviar los datos de un formulario con el método GET respecto al método POST con HTTP?
Respuesta: Con GET, los datos se envían a través de la URL en la línea de petición HTTP; con POST, se envían como una entidad en el cuerpo de la petición.
Pregunta: ¿Qué problema de eficiencia supone el no implementar conexiones persistentes en HTTP/1.0?
Respuesta: Se añade retardo en el acceso a la información debido a la necesidad de establecer una nueva conexión TCP para cada recurso, además de una mayor sobrecarga de datos no relacionados con la aplicación.
Pregunta: ¿Qué característica de las siguientes NO se mantiene en HTTP/2 con respecto a HTTP/1.1?
Respuesta: La estructura de las peticiones (HTTP/2 introduce frames y streams).
Pregunta: ¿Cuál de las siguientes líneas de estado de HTTP/1.1 corresponde con la respuesta a una petición POST que se ha realizado correctamente?
Respuesta: HTTP/1.1 200 OK.

Conceptos Fundamentales de HTTP

Protocolo sencillo surgido de la necesidad de enviar documentos de hipertexto en el CERN (Instituto Europeo de Investigación Nuclear).
Actualmente conviven fundamentalmente HTTP/1.1 y HTTP/2.

Versiones de HTTP

HTTP/0.9

Primera versión creada.
Utilizaba conexiones transitorias: una conexión TCP para cada recurso (documento de hipertexto, imagen, clip multimedia, etc.), lo que generaba un desperdicio de recursos.

HTTP/1.0

También utilizaba conexiones transitorias por defecto.

HTTP/1.1

Soporte de múltiples nombres de host (cabecera Host).
Conexiones persistentes: Permite que el cliente solicite todos los recursos necesarios a través de la misma conexión TCP, reduciendo la sobrecarga de establecimiento de conexión.
Pipelining: Permite el encadenamiento de peticiones HTTP al servidor sin tener que esperar a que las realizadas previamente sean respondidas (aunque añade complejidad al cliente y no siempre se implementa).
Selección de recurso parcial.
Negociación del contenido.
Las líneas terminan con CRLF (retorno de carro y salto de línea).
La línea en blanco es un separador entre cabeceras y cuerpo.

HTTP/2.0

Desarrollado por el grupo HTTPbis del IETF.
No busca dejar obsoleta la versión HTTP/1.1, sino ofrecer una alternativa de mayor rendimiento.
Se espera que su vida útil sea más corta debido a la aparición de HTTP/3 (basado en QUIC), que ya está en fase de borrador.
Trata de mejorar el rendimiento de HTTP/1.1 en el nuevo entorno del servicio web e Internet del siglo XXI.
Problemas que resuelve de HTTP/1.1:
- Las peticiones se tenían que resolver en orden (Head-of-Line Blocking).
- Cabeceras repetitivas y demasiado largas.
Nuevas funcionalidades:
- Multiplexado: Mezcla mensajes de petición y respuesta en la misma conexión TCP (mediante streams).
- Cambio en la estructura de las peticiones (uso de frames).
- Codificación eficiente de las cabeceras (HPACK).
- Priorización de peticiones.
- Todo esto para reducir el número de conexiones TCP y mejorar la eficiencia.

Métodos HTTP Comunes

GET:
- Obtiene el recurso especificado en el URI del servidor web.
- En HTTP/1.1, la cabecera Host es obligatoria.
- La URL puede incluir parámetros de consulta (query) para definir aspectos relacionados con el recurso solicitado.
- Los datos enviados en una query no deben ser confidenciales.
POST:
- Permite al cliente enviar información al servidor para que sea procesada por un recurso.
- La URL contiene el recurso que debe recibir los datos enviados por el cliente.
- Una petición POST lleva los datos en el cuerpo de la entidad.
HEAD:
- Similar a GET, pero el servidor no envía el cuerpo del recurso, solo las cabeceras. Útil para obtener metadatos sin descargar el contenido completo.

Etiquetas: HTTP, OSI, REST, SOAP, TCP/IP

Fundamentos Clave de Desarrollo Web y Redes: Protocolos, Arquitecturas y Rendimiento