Ingeniería Web: razona peticiones HTTP, estados y permisos

1. Sigue una petición de principio a fin

El navegador solicita un recurso y el servidor devuelve una respuesta. En una aplicación dinámica, el servidor puede consultar datos, aplicar reglas y construir el resultado. El navegador interpreta el HTML recibido y puede pedir después hojas de estilo, imágenes o datos adicionales.

Imagina un catálogo de libros. Al abrir la ficha 42, el navegador solicita esa ficha; el servidor busca el libro, prepara una representación y la devuelve. El contenido visible puede ser HTML o formarse a partir de datos que recibe el cliente. En ambos casos, la existencia de la ficha debe decidirse con los datos reales.

Para explicar una arquitectura, dibuja cuatro pasos: petición, validación, operación y respuesta. Añade qué parte ocurre en cada lado. No basta con llamar «backend» a una caja: indica qué comprueba y qué devuelve. Tampoco confundas el servidor con la base de datos; esta es uno de los recursos que puede utilizar.

2. El método expresa la intención

GET solicita una representación y tiene semántica de lectura. POST pide procesar el contenido enviado según el recurso. PUT crea o reemplaza el estado del recurso de destino. DELETE solicita retirar la asociación del recurso. El significado del método ayuda a que clientes e intermediarios sepan qué esperar.

Para una lista de tareas de ejemplo, consultar /tareas/42 encaja con GET. Enviar una nueva tarea a una colección puede usar POST. La elección del método no implementa por sí sola validaciones, permisos ni protección contra solicitudes repetidas: el servidor debe aportar esas reglas.

Idempotente significa que repetir la misma petición tiene el mismo efecto previsto sobre el servidor que ejecutarla una vez. No significa que todas las respuestas deban ser idénticas. Si un DELETE elimina una tarea, una repetición puede recibir 404 porque ya no está; el efecto sigue siendo que esa tarea no existe.

3. Lee el resultado antes de culpar a la interfaz

Un 200 indica que la petición se atendió correctamente; un 404, que no se encontró el recurso; un 403 expresa que el servidor rechaza atenderla. Un 500 señala una condición inesperada del servidor. El estado resume el resultado HTTP, pero para diagnosticar necesitas contrastarlo con la operación que pretendías realizar.

Supón que la ficha 42 fue borrada y la interfaz sigue mostrando el enlace. Si al abrirlo recibes 404, hay una referencia que revisar. Si recibes 200 con datos correctos pero la pantalla queda vacía, investiga cómo la interfaz interpreta y presenta esos datos. Una pantalla vacía, sin observar la respuesta, no permite localizar la causa.

En un ejercicio de diagnóstico, escribe primero la evidencia: ruta solicitada, estado y contenido recibido. Después formula una hipótesis comprobable. Evita convertir «no carga» en «la base de datos está caída» sin un dato que conecte ambas cosas.

4. Identidad y permiso se comprueban por separado

Autenticar es comprobar quién realiza una petición. Autorizar es decidir si puede realizar esa acción sobre ese recurso. Una sesión válida no da acceso a todos los documentos de una aplicación. El servidor debe comprobar los permisos pertinentes en cada petición.

En una libreta privada, Ana puede tener permiso para leer su nota 42 y no la nota 43 de otra persona. Ocultar el enlace a la segunda en la interfaz mejora la navegación, pero no protege el recurso: una petición directa todavía puede llegar al servidor. La comprobación debe relacionar usuario, acción y nota.

Para evaluar el diseño, inventa dos usuarios y dos notas con propietarios distintos. Verifica la lectura propia, la lectura ajena y la petición sin sesión. No necesitas datos reales para razonar los casos. Una prueba que solo confirma que aparece el botón no comprueba la autorización.

Ejercicios resueltos para comprobar lo aprendido

Intenta explicar tu respuesta en papel antes de abrir la solución. Después compara el razonamiento, no solo el resultado.

Fuentes de consulta

Estas referencias explican los conceptos de la guía. Los ejemplos y las soluciones están redactados para Quizy; las fuentes no han revisado ni avalado esta página.

• Interacción entre cliente y servidor — MDN
• Semántica HTTP — IETF, RFC 9110
• Comprobación de permisos — OWASP

Revisión docente independiente pendiente. Si detectas un error, escríbenos indicando el apartado. Cómo describimos la calidad del contenido.