Objeto Response y Status HTTP en Fetch API

Introducción al Objeto Response

El objeto Response es lo que retorna la promesa de fetch() cuando se resuelve. Este objeto contiene toda la información sobre la respuesta HTTP: el código de status, los headers, el tipo de contenido, y el cuerpo de la respuesta. Es importante entender cómo usar este objeto correctamente, ya que es tu interfaz principal para interactuar con las respuestas del servidor.

Una característica importante del objeto Response es que el cuerpo de la respuesta es un stream que solo se puede leer una vez. Si intentas leer el cuerpo múltiples veces, recibirás un error. Para leer el cuerpo múltiples veces, debes clonar el objeto Response usando el método clone(). Esto es especialmente útil cuando necesitas procesar el cuerpo de diferentes formas o cuando quieres guardar una copia para uso posterior.

• <strong>status</strong>: Código de status HTTP (200, 404, 500, etc.)
• <strong>ok</strong>: Booleano true para códigos 200-299, false para otros
• <strong>headers</strong>: Objeto Headers con los headers de la respuesta
• <strong>type</strong>: Tipo de respuesta (basic, cors, error, opaque)
• <strong>body</strong>: Stream del cuerpo de la respuesta (solo se puede leer una vez)

Propiedades del Objeto Response

El objeto Response tiene varias propiedades que te dan información sobre la respuesta HTTP. La propiedad más importante es ok, que es un booleano que indica si la respuesta fue exitosa (códigos 200-299) o no. La propiedad status contiene el código de status HTTP exacto, lo que te permite manejar diferentes casos de error de forma específica.

Este ejemplo muestra las propiedades principales del objeto Response.ok es true para códigos de éxito (200-299) y false para cualquier otro código. status contiene el código exacto, lo que te permite manejar diferentes casos de error de forma específica. statusTextcontiene el mensaje descriptivo del status (como "OK", "Not Found", "Internal Server Error").type indica el tipo de respuesta, que es importante para entender las limitaciones de la respuesta en ciertos casos como CORS.

Este ejemplo muestra cómo verificar ok para determinar si la respuesta fue exitosa. Si ok es false, puedes lanzar un error manualmente o manejar el caso según tus necesidades. Es importante notar queok es true solo para códigos 200-299, por lo que códigos de redirección (3xx) se considerarán como no exitosos. El tipo de respuesta (response.type) puede ser 'basic', 'cors', 'error', o 'opaque', siendo las respuestas 'opaque' las que tienen limitaciones severas en el acceso al cuerpo y headers.

Códigos de Status HTTP

Los códigos de status HTTP son números de tres dígitos que indican el resultado de la petición HTTP. Están divididos en cinco categorías: 1xx (informativo), 2xx (éxito), 3xx (redirección), 4xx (error del cliente), y 5xx (error del servidor). Entender estos códigos es crucial para manejar correctamente las respuestas y proporcionar una buena experiencia de usuario.

• <strong>2xx (Éxito)</strong>: 200 OK, 201 Created, 204 No Content
• <strong>3xx (Redirección)</strong>: 301 Moved Permanently, 302 Found, 304 Not Modified
• <strong>4xx (Error del cliente)</strong>: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
• <strong>5xx (Error del servidor)</strong>: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
• <strong>response.ok</strong>: Es true solo para códigos 2xx (200-299)

Este ejemplo muestra cómo manejar diferentes códigos de status HTTP de forma específica. En lugar de simplemente verificar ok, puedes usar un switch o if/else para manejar diferentes casos de error de forma específica. Esto te permite proporcionar mensajes de error más específicos y tomar acciones diferentes según el tipo de error.

Métodos del Objeto Response

El objeto Response tiene varios métodos para leer el cuerpo de la respuesta en diferentes formatos. El método que uses depende del tipo de contenido que esperas recibir del servidor. .json() es el más común para APIs REST modernas, .text() se usa para texto plano, .blob()para archivos binarios como imágenes, y .arrayBuffer() para datos binarios crudos.

Este ejemplo muestra los diferentes métodos para leer el cuerpo de la respuesta..json() parsea el cuerpo como JSON y retorna un objeto JavaScript,.text() retorna el cuerpo como texto plano, .blob()retorna un Blob (útil para archivos binarios), y .arrayBuffer()retorna un ArrayBuffer (útil para datos binarios crudos). Cada método retorna una promesa que se resuelve con el cuerpo en el formato especificado.

Este ejemplo muestra el error común de intentar leer el cuerpo de la respuesta múltiples veces. El cuerpo de la respuesta es un stream que solo se puede leer una vez. Si intentas leerlo múltiples veces, recibirás un error. Para leer el cuerpo múltiples veces, debes clonar el objeto Response usando el métodoclone() antes de leer el cuerpo.

Headers de la Respuesta

Los headers de la respuesta contienen metadatos importantes sobre la respuesta, como el tipo de contenido, la fecha de modificación, información de caching, y más. Puedes acceder a los headers a través de la propiedad headersdel objeto Response, que es un objeto Headers con métodos para leer, verificar, y manipular los headers.

Este ejemplo muestra cómo leer los headers de la respuesta. Puedes usar.get() para obtener un header específico, .has() para verificar si un header existe, .forEach() para iterar sobre todos los headers, o acceder a los headers directamente usando notación de corchetes. Ten en cuenta que algunos headers pueden no estar disponibles por razones de seguridad, especialmente en respuestas CORS.

Este ejemplo muestra cómo acceder a headers específicos que son comúnmente usados en aplicaciones web. Content-Type indica el tipo de contenido de la respuesta, Content-Length indica el tamaño del cuerpo en bytes, Cache-Control contiene directivas de caching, y ETag es un identificador único de la versión del recurso. Estos headers son útiles para optimizar el rendimiento y manejar el caching.

Clonar Responses

Como mencionamos anteriormente, el cuerpo de la respuesta es un stream que solo se puede leer una vez. Si necesitas leer el cuerpo múltiples veces, debes clonar el objeto Response usando el método clone(). Este método crea una copia del objeto Response con su propio stream independiente, permitiéndote leer el cuerpo múltiples veces sin errores.

Este ejemplo muestra cómo clonar el objeto Response para leer el cuerpo múltiples veces. El método clone() crea una copia del objeto Response con su propio stream independiente. Esto es útil cuando necesitas procesar el cuerpo de diferentes formas o cuando quieres guardar una copia para uso posterior. Ten en cuenta que clonar la respuesta consume memoria adicional, ya que se mantiene una copia del cuerpo en memoria.

Este ejemplo muestra un caso de uso práctico de clonar responses: implementar caching simple en memoria. Al clonar la respuesta, puedes guardar una copia para uso posterior mientras lees el cuerpo original. Esto es útil para evitar peticiones repetidas al mismo recurso, mejorando el rendimiento de tu aplicación. Ten en cuenta que este es un cache simple y no persistente entre recargas de la página.

Errores Comunes

Al trabajar con el objeto Response, hay varios errores comunes que los desarrolladores cometen. Uno de los errores más frecuentes es intentar leer el cuerpo de la respuesta múltiples veces sin clonar primero. Como mencionamos, el cuerpo es un stream que solo se puede leer una vez, y intentar leerlo múltiples veces causará un error.

Este ejemplo muestra el error común de intentar leer el cuerpo múltiples veces. La primera llamada a .json() consume el stream del cuerpo, por lo que la segunda llamada fallará con un error. Para evitar esto, debes clonar la respuesta antes de leer el cuerpo o guardar el resultado de la primera lectura para uso posterior.

Otro error común es no verificar ok o status antes de procesar la respuesta. Como mencionamos, Fetch no rechaza la promesa en errores HTTP, por lo que debes verificar manualmente si la respuesta fue exitosa. Si no lo haces, podrías intentar procesar una respuesta de error como si fuera exitosa, causando comportamientos inesperados.