Empieza con un mapa de solicitudes
Al presupuestar una función de conversaciones sobre offline maps para una app de senderismo, el primer paso es entender que los costes dependen de las solicitudes de recuperación, no del volumen devuelto. Una búsqueda correcta cuesta un crédito, tanto si devuelve tres registros como 100 o una lista vacía. Una página menor puede mejorar la lectura, pero no reduce el precio en créditos de esa solicitud.
Identifica las acciones que realmente llegan al servicio. La primera búsqueda, una página siguiente solicitada, una actualización explícita y una consulta de un registro pueden ser recuperaciones separadas. Desplazarse por texto ya cargado no genera otra solicitud. Pulsar una vez no equivale necesariamente a un crédito si tu backend lo convierte en varias llamadas.
Calcula un día supuesto
Este es un ejemplo de planificación, no tráfico observado ni una previsión: supón que la app completa 120 solicitudes de primera página, 30 de páginas adicionales y 10 actualizaciones. Son 160 solicitudes correctas y 160 créditos, equivalentes a $0.16 a la tarifa indicada. Si 20 primeras páginas están vacías, el total sigue siendo 160 créditos porque esas solicitudes tuvieron éxito.
Ahora supón que la interfaz recupera automáticamente tres páginas por cada búsqueda inicial aunque nadie las lea. Serían 360 solicitudes antes de contar actualizaciones, en lugar de las 150 solicitudes iniciales y siguientes deliberadas del primer ejemplo. La comparación es aritmética bajo supuestos explícitos, no evidencia sobre usuarios reales. Tras implementar, sustituye los supuestos por tu propio registro medido de solicitudes.
Separa el precio de la compra
La tarifa estándar es $1 por 1,000 recuperaciones correctas. La recarga mínima es $50 y proporciona 50,000 créditos de pago. No hay suscripción y los créditos comprados no caducan. Por tanto, un día hipotético de $0.16 describe consumo de saldo; no implica que exista una recarga de $0.16.
La prueba opcional de 100 créditos está sujeta a elegibilidad contra el abuso en toda la red y es independiente de la conversión de pago. No supongas que todos los registros la reciben ni presentes la función como una API gratuita. Crea una factura con la sesión iniciada y utiliza su importe exacto, destinatario, token y red. Clave y créditos contiene los pasos de cuenta y pago.
Distingue fallos e incertidumbre
HTTP 400, 401, 402 y 429 se rechazan antes de reservar un crédito de recuperación. Indican respectivamente entrada inválida, clave ausente o inválida, créditos insuficientes y límite de solicitudes. Una solicitud fallida a la fuente ascendente libera el crédito reservado, aunque la conciliación puede quedar pendiente. No describas todos los errores como un reintegro inmediato de un cobro anterior.
Si la app pierde la respuesta después de enviar la solicitud, puede no saber si el servidor completó una recuperación correcta. Un reintento es otra solicitud, no una continuación gratuita garantizada. Registra el resultado incierto, conserva la consulta y evita una avalancha de reintentos automáticos. La vista de cuenta expone recuentos correctos, pendientes y reintegrados para conciliar.
Pon un límite a la función
Cada consulta permite páginas 1–100 y hasta 100 registros por solicitud. Son límites del servicio, no una recomendación de recuperar todas las páginas. La app puede elegir un presupuesto de páginas menor por sesión de lectura y preguntar antes de continuar. Respeta pagination.has_more y el límite de la ventana final en lugar de buscar una página vacía con solicitudes repetidas.
No cuentes la ventana potencial de 10,000 registros como un rendimiento garantizado. Una respuesta puede estar vacía, pueden faltar campos y el archivo no promete cobertura completa. /v1/status no se cobra, pero no devuelve el saldo ni comprueba el estado de búsqueda. Los contadores locales también necesitan conciliación; no prueban que una solicitud perdida fuera gratuita.
Revisa las elecciones que necesita el lector
Para el panel de senderismo propuesto, una primera página breve y Mostrar más deliberado pueden bastar para comparar referencias. Guarda o vuelve a abrir contenido ya almacenado por la app sin recuperarlo otra vez silenciosamente. Si alguien solicita comprobar de nuevo un registro, explica que es una consulta nueva y gestiona su posible ausencia.
Usa tu propio tráfico como evidencia para decidir si ajustar límites o presentación. No conviertas el ejemplo de planificación en un coste por usuario, tasa de retención o referencia de rendimiento prometidos. Regresa a /es/#field-notes para la paginación acotada y el diseño de listas locales.
