Manejo de errores, límites de tasas y mejores prácticas
Una integración de nivel de producción debe manejar los errores de API con elegancia, respetar los límites de velocidad y seguir las mejores prácticas de almacenamiento en caché y rendimiento. Este artículo cubre los tres temas para ayudarle a crear una integración confiable y eficaz.
Formato de respuesta de error
Cuando falla una llamada API, el cuerpo de la respuesta contiene un error estructurado:
{
"message": "Description of the error",
"status": 400
}Algunas respuestas de error incluyen detalles adicionales:
{
"error": {
"message": "Detailed error description",
"status": 400
}
}*
Códigos de estado HTTP
| Estado | Significado | Común Causas | Acción |
|---|---|---|---|
| Éxito | Solicitud completado normalmente. | Procesar la respuesta datos. | |
400 | Bad Solicitud | Faltan parámetros requeridos, formato de fecha no válido, coordenadas no válidas, cuerpo de solicitud mal formado. | Valide los datos de su solicitud antes de enviarla. Verifique los campos y datos requeridos tipos. |
401XEN IKBPH50 | No autorizado | Desaparecido, Firma de API caducada o no válida. | Genere una nueva firma y vuelva a intentar la solicitud. |
404 | No Encontrado | ID de propiedad, ID de reserva o ruta del punto final no válidos. | Verifique que el ID exista y que la URL del punto final sea correcto. |
429 | Demasiados Solicitudes | Límite de velocidad excedido. | Retroceda y vuelva a intentarlo después de que se restablezca la ventana. Consulte Límites de velocidad a continuación. |
500 | Servidor interno Error | Problema inesperado del lado del servidor. | Reintente después de un breve retraso. Si persiste, comuníquese con el soporte. |
503 | Servicio No disponible | API no está disponible temporalmente (mantenimiento, sobrecarga). | Reintentar con exponencial retroceso. |
*
Manejo de errores por punto final
Errores de autenticación (401)
La causa más común es una firma caducada. Implemente la lógica de actualización automática (consulte Autenticación y firmas API) y vuelva a intentar la solicitud fallida con la nueva firma.
async function apiCall(method, endpoint, data, correlationId) { let signature = await signatureManager.getSignature();
try { return await makeRequest(method, endpoint, data, signature, correlationId); } catch (error) { if (error.status === 401) { // Signature may have expired — force refresh and retry once signature = await signatureManager.forceRefresh(); return await makeRequest(method, endpoint, data, signature, correlationId); } throw error; }}
Errores de búsqueda (sin resultados)
Una búsqueda de hotel puede arrojar cero resultados sin un estado de error. Esto no es una falla de API; significa que ninguna propiedad coincide con sus criterios. Maneje esto por:
- Sugerir ubicaciones cercanas o rangos de fechas más amplios.
- Filtros relajantes (por ejemplo, eliminar calificación de estrellas o restricciones de precio).
- Mostrar un mensaje amigable de "no hay resultados".
Errores de disponibilidad
Las habitaciones pueden dejar de estar disponibles entre la búsqueda y la verificación de disponibilidad. Si la respuesta de disponibilidad devuelve una matriz vacía:
- Informar al usuario que la habitación ya no está disponible.
- Sugerir volver a buscar o consultar un hotel diferente.
Errores de precios
Si la confirmación del precio falla o el token no es válido:
- Vuelva a ejecutar la verificación de disponibilidad para obtener un token de disponibilidad nuevo.
- Confirma el precio nuevamente para obtener un nuevo token de precio.
- Avisar al huésped si el precio ha cambiado.
Errores de reserva
Los errores en las reservas pueden ocurrir debido a tokens de precios vencidos, habitaciones agotadas o datos de huéspedes no válidos. Siempre:- Validar la información del huésped en el lado del cliente antes de enviarla.
- Verifique la frescura del token de precios (período de 10 minutos) antes de reservar.
- Mostrar un mensaje de error claro y ofrecer la opción de volver a intentarlo.
*
Límites de tarifas
La API de Xeni Hotels impone límites de tarifas para garantizar un uso justo y la estabilidad del sistema.
| Alcance | Límite | XENIKBPH_118__Ventana|
|---|---|---|
| General Llamadas API | 100 solicitudes | 15 minutos |
| Chat/mensaje puntos finales | 20 solicitudes | 5 minutos |
Encabezados de límite de tasa
La información del límite de tasa se incluye en los encabezados de respuesta:
| Encabezado | Descripción |
|---|---|
RateLimit-Limit | Máximo número de solicitudes permitidas en el window. |
RateLimit-Remaining | Número de solicitudes restantes en el actual window. |
RateLimit-Reset | Marca de tiempo (segundos) cuando se restablece la ventana de límite de velocidad. |
Manejo de 429 Respuestas
Cuando recibe una respuesta 429:
- Deja de hacer solicitudes inmediatamente.
- Espere hasta que se restablezca la ventana de límite de velocidad (verifique el encabezado
RateLimit-Reset). - Reanudar con patrones de solicitud normales.
No vuelva a intentar solicitudes con velocidad limitada en un ciclo cerrado; esto extenderá el período de recuperación.
*
Recomendaciones de almacenamiento en caché
El almacenamiento en caché inteligente reduce las llamadas API, mejora los tiempos de respuesta y se mantiene dentro de los límites de velocidad. A continuación se muestran las duraciones de caché recomendadas por tipo de datos:
| Tipo de datos | Recomendado TTL | Justificación |
|---|---|---|
| Autocompletar ubicación resultados | 1 hora | Las ubicaciones rara vez cambian. Es seguro almacenar en caché de forma agresiva. |
| Detalles del hotel (información de la propiedad) | 1 hora | Las descripciones, servicios y fotos del hotel no cambian con frecuencia. |
| Búsqueda de hotel resultados | 30 minutos | Los precios y la disponibilidad cambian con el tiempo. Caché para reutilización a corto plazo. |
| Disponibilidad de habitaciones | 5 minutos | Altamente volátil. Las habitaciones se agotan y los precios cambian rápidamente. |
| Confirmaciones de precios | No cache | Cada confirmación de precio es única y específica del token. Llame siempre a la API nueva. |
Estrategia de clave de caché
Genere claves de caché únicas a partir de los parámetros de solicitud. Un enfoque común:
// JavaScriptimport crypto from 'crypto';
function generateCacheKey(prefix, params) { const hash = crypto.createHash('md5') .update(JSON.stringify(params)) .digest('hex'); return cache:${prefix}:${hash};}
// Examples:generateCacheKey('location', { query: 'miami' });// → "cache:location:3f8c9a2b..."
generateCacheKey('search', { lat: 25.76, long: -80.19, checkIn: '2025-06-01', checkOut: '2025-06-05' });// → "cache:search:7d2e1f4a..."
*
Configuración de tiempo de espera
Establezca tiempos de espera de solicitud adecuados para cada llamada API. Nuestras recomendaciones:
| Punto final | Recomendado Tiempo de espera |
|---|---|
| Generación de firma | 10 segundos |
| Autocompletar ubicación | 10 segundos |
| Búsqueda de hotel | 30 segundos |
| Detalles del hotel | 15 segundos |
| Verificación de disponibilidad | 30 segundos |
| Confirmación de precio | 15 segundos |
| Creación de reserva | 30 segundos |
La búsqueda de hoteles y las comprobaciones de disponibilidad pueden tardar más porque consultan a varios proveedores en tiempo real.
*
Estrategia de reintento
No todos los errores son permanentes. Utilice una estrategia de reintento con retroceso exponencial para fallas transitorias:
| Error Tipo | ¿Reintentar? | Estrategia | XENIKB PH_304
|---|---|---|
401 No autorizado | Sí (una vez) | Actualizar firma, luego reintentar. |
429 Tarifa limitada | Sí (después espere) | Espere la ventana de reinicio, luego reintentar. |
500 Error del servidor | Sí (hasta 3) | Retroceso exponencial: esperar 1s, 2s, 4s. |
503 No disponible | Sí (hasta 3) | Retroceso exponencial: esperar 2s, 4s, 8s. |
400 Malo Solicitud | No | Corregir la solicitud. Volver a intentarlo con los mismos datos producirá el mismo error. |
404 No Encontrado | No | Verifique el ID del recurso. Volver a intentarlo no ayudará. |
Ejemplo: Reintentar con retroceso exponencial
async function apiCallWithRetry(fn, maxRetries = 3) { for (let attempt = 0; attempt <= maxRetries; attempt++) { try { return await fn(); } catch (error) { const status = error.response?.status;
// Don't retry client errors (except 401 and 429) if (status && status >= 400 && status < 500 && status !== 401 && status !== 429) { throw error; }
if (attempt === maxRetries) throw error;
const delay = Math.pow(2, attempt) * 1000; // 1s, 2s, 4s await new Promise(resolve => setTimeout(resolve, delay)); } }}
*
Lista de verificación de preparación para la producción
Antes de publicarla, verifique que su integración cumpla con estos criterios:
| Artículo | Detalle s | |
|---|---|---|
| ☐ | Firma actualización automática | Actualización de firmas antes de que expiren los 30 minutos window. |
| ☐ | Gestión de ID de correlación | Capturado de primera respuesta y reenviado en todas las llamadas posteriores. Reemplazado en búsquedas de nuevas ubicaciones. |
| ☐ | Ciclo de vida del token manejo | Los tokens de disponibilidad se utilizan solo para fijar precios. Para realizar la reserva se utilizan tokens de precios (TTL de 10 minutos). La caducidad se comprueba antes de su uso. |
| ☐ | Error manejo | Se manejan todos los códigos de error HTTP. 401 activa la actualización de la firma. 429 activa el retroceso. |
| ☐ | Límite de velocidad cumplimiento | La aplicación respeta los límites de velocidad y no vuelve a intentar los 429 agresivamente. |
| ☐ | Almacenamiento en caché | Ubicaciones y detalles del hotel están almacenados en caché. La disponibilidad se almacena en caché brevemente o no en all. |
| ☐ | Tiempos de espera | Todas las llamadas API tienen tiempos de espera configurados. |
| ☐ | Seguridad de credenciales | API La clave y el secreto se almacenan en variables de entorno, no en el código fuente. |
| ☐ | Environment configuración | UAT y las URL base de producción son configurables, no codificado. |
| ☐ | Degradación elegante | Si se almacena en caché La capa (Redis) no está disponible, la aplicación recurre a la API directa. llamadas. |
| ☐ | Registro | Llamadas API, errores y los eventos clave se registran para depuración y monitoreo. |
| ☐ | Health comprobaciones | La aplicación expone un punto final de salud que verifica la conectividad a las dependencias (Redis, estado de firma de API de Xeni). |
*
Obtener ayuda
Si encuentra problemas que no se resuelven con esta documentación:
- Compruebe el mensaje de error: La API devuelve mensajes de error descriptivos que normalmente apuntan a la causa raíz.
- Verifique primero en UAT: Pruebe su solicitud en el entorno UAT para aislar el problema.
- Comuníquese con soporte: Comuníquese con su representante de cuenta Xeni con los siguientes detalles:
- La solicitud API completa (punto final, encabezados, cuerpo)
- La respuesta API completa (código de estado, encabezados, cuerpo)
- El ID de correlación de la sesión.
- La marca de tiempo de la solicitud.