Cuándo usar los códigos de estado HTTP (y cuándo no)

Al construir una API o una aplicación web, entender los códigos de estado HTTP es crucial. Estos códigos forman la columna vertebral de la comunicación entre cliente y servidor, ayudándote a transmitir el resultado de las solicitudes enviadas a los recursos de tu aplicación. Un error común durante las entrevistas técnicas es manejar incorrectamente estos códigos, lo que puede llevar a confusiones no solo en la comunicación con los clientes, sino también a problemas funcionales en producción. Vamos a profundizar en cómo usar estos códigos de manera efectiva, específicamente cuándo utilizarlos y cuándo podrían engañar a los usuarios o desarrolladores.

Códigos de estado HTTP y sus casos de uso

Entre la multitud de códigos de estado HTTP, los más comúnmente encontrados se clasifican por su primer dígito:

• 1xx (Informativo): No se utiliza ampliamente en la práctica, pero indica una respuesta provisional.
• 2xx (Éxito): Indica solicitudes exitosas. Códigos como 200 OK (GET exitoso) y 201 Created (POST exitoso) son esenciales para indicar que la solicitud fue procesada como se esperaba.
• 3xx (Redirección): Indica que se necesita tomar más acción para completar la solicitud.
• 4xx (Error del cliente): Indica que la solicitud contiene una sintaxis incorrecta o no puede ser cumplida, por ejemplo, 404 Not Found, 403 Forbidden, y 400 Bad Request.
• 5xx (Error del servidor): Indica que el servidor no pudo cumplir una solicitud válida, como 500 Internal Server Error o 503 Service Unavailable.

Usar estos códigos correctamente no solo informa a los usuarios sobre lo que salió mal, sino que también ayuda a los desarrolladores a solucionar problemas de manera efectiva.

Elegir entre los códigos de estado 400 y 500

Una tensión que los candidatos suelen enfrentar en entrevistas es decidir cuándo usar un 400 Bad Request frente a un 500 Internal Server Error. Es fundamental acertar en esto.

• Usa 400 Bad Request cuando el cliente envía una solicitud no válida que el servidor no puede procesar debido a problemas del lado del cliente. Por ejemplo, si un usuario envía un formulario con datos inválidos.
• Usa 500 Internal Server Error cuando algo sale mal en el lado del servidor que no ha sido causado por el cliente, lo que lo convierte en un problema del servidor fuera del control del cliente.

Esta distinción informa al cliente si debe corregir su entrada o esperar a que se resuelvan los problemas del servidor, lo cual es esencial para proporcionar una buena experiencia de usuario. Veamos un ejemplo de código mínimo de cómo podrían implementarse estos en Express.js, un marco común de Node.js:

app.post('/submit', (req, res) => {
    const { data } = req.body;
    if (!data || typeof data !== 'string') {
        return res.status(400).json({ error: 'Entrada no válida proporcionada.' }); // Solicitud incorrecta
    }
    // Procesar la lógica de solicitud válida aquí...
    // Si ocurre un error internamente:
    // return res.status(500).json({ error: 'Error interno del servidor.' }); // Error interno del servidor
});

Este fragmento de código verifica si el data entrante es válido antes de continuar. Si no lo es, envía un código de estado 400 que indica un error del cliente. Este tipo de validación es esencial.

Trampas en la entrevista

Los candidatos suelen pasar por alto la importancia de los códigos de estado durante las entrevistas. Aquí están los errores comunes y aspectos en los que los entrevistadores pueden presionar:

• Usar 500 para errores del cliente: Confundir problemas del lado del servidor con errores del lado del cliente puede llevar a procesos de depuración erróneos. Se debe saber cuándo identificar la fuente del error.
• Documentación vaga: Espera que las entrevistas insistan en cómo podrías documentar las respuestas de tu API. Una documentación clara ayudará a consumir mejor las APIs.
• Suponer comportamiento predeterminado en marcos: Al usar herramientas como Express, entiende cómo gestionan las respuestas de estado en errores y asegúrate de sobrescribir los valores predeterminados cuando sea necesario.
• Pasar por alto códigos específicos: Los candidatos pueden no darse cuenta de la importancia de usar códigos más específicos, como 403 Forbidden para errores de permiso en lugar de un genérico 404 Not Found.

Un ejemplo trabajado

Analicemos un posible escenario de entrevista:

Escenario: Desarrollas un punto final de API para que los usuarios obtengan sus perfiles. Si un usuario solicita un perfil que no existe, ¿cómo respondes?

1. Identificar la Solicitud: Cuando un usuario solicita un perfil que no se puede encontrar.
2. Seleccionar el Código de Estado Correcto:
   • Una respuesta 404 Not Found es apropiada aquí porque establece claramente que el recurso (perfil) no existe.
3. Implementar:

app.get('/user/:id', (req, res) => {
    const userProfile = findUserById(req.params.id);
    if (!userProfile) {
        return res.status(404).json({ error: 'Usuario no encontrado.' });
    }
    return res.status(200).json(userProfile);
});

Este código distingue claramente entre los casos encontrados y no encontrados, facilitando una mejor resolución de problemas y retroalimentación del usuario.

En el trabajo

En producción, los códigos de estado HTTP mal gestionados pueden llevar a problemas significativos. Por ejemplo, si un cliente recibe un error 500 erróneamente atribuido a su solicitud, puede perder tiempo intentando arreglar lo que no está roto. Por otro lado, no adherirse a los códigos apropiados podría resultar en un comportamiento inesperado en las aplicaciones del cliente, especialmente aquellas construidas sobre tu API, que esperan un conjunto específico de respuestas para manejar errores de manera robusta.

Conclusión

En resumen, saber cuándo usar el código de estado HTTP correcto es tan crucial como entender los propios códigos de estado. Empodera a los usuarios, crea transparencia y facilita una depuración más rápida. A medida que te prepares para tus entrevistas y avanzas en tu rol, ten en cuenta estas distinciones y úsalas para construir mejores APIs.

Referencias

• MDN Web Docs - Códigos de estado de respuesta HTTP
• Guía de Express.js - Manejo de errores
• Códigos de estado HTTP - W3C
• ¿Qué son los códigos de estado HTTP? - Tutorial de API REST