Partire da una mappa delle richieste
Per pianificare il budget di una funzione sulle discussioni di mappe offline in un’app escursionistica, bisogna anzitutto capire che il costo dipende dalle richieste di recupero, non dalla quantità di dati restituiti. Una ricerca riuscita costa un credito sia con tre record sia con 100 o una lista vuota. Una pagina più piccola può migliorare la lettura, ma non riduce il prezzo in crediti della richiesta.
Disegna le azioni che raggiungono davvero il servizio. Prima ricerca, pagina successiva richiesta, aggiornamento esplicito e consultazione di un elemento possono essere recuperi distinti. Scorrere testo già caricato non è una nuova richiesta. Premere un pulsante non equivale necessariamente a un credito se il backend suddivide l’azione in più chiamate.
Calcolare una giornata ipotetica
Ecco un esempio di pianificazione, non traffico osservato o una previsione d’uso: supponi che l’app completi 120 richieste di prima pagina, 30 di pagine aggiuntive e 10 aggiornamenti. Sono 160 richieste riuscite e 160 crediti, equivalenti a $0.16 alla tariffa indicata. Se 20 delle risposte di prima pagina sono vuote, il totale resta 160 crediti perché quelle richieste sono comunque riuscite.
Supponi ora che l’interfaccia carichi automaticamente tre pagine per ogni ricerca iniziale anche quando nessuno le legge. Sarebbero 360 richieste prima degli aggiornamenti, anziché le 150 richieste iniziali e aggiuntive deliberate del primo esempio. È un confronto aritmetico basato su ipotesi dichiarate, non una prova sugli utenti reali. Dopo l’implementazione sostituisci le ipotesi con il tuo log misurato delle richieste.
Distinguere la tariffa dall’acquisto
La tariffa standard è $1 ogni 1.000 recuperi riusciti. La ricarica minima è $50 e fornisce 50.000 crediti acquistati. Non c’è abbonamento e questi crediti non scadono. Una giornata ipotetica da $0.16 descrive quindi il consumo di un saldo, non la disponibilità di una ricarica da $0.16.
La prova facoltativa da 100 crediti dipende dall’idoneità antiabuso a livello di rete ed è separata dalla conversione a pagamento. Non presumere che ogni iscrizione la riceva e non presentare la funzione come API gratuita. Crea una fattura dopo l’accesso, poi segui importo esatto, destinatario, token e rete indicati. Chiave e crediti contiene i passaggi dell’account e del pagamento.
Distinguere i fallimenti dall’incertezza
HTTP 400, 401, 402 e 429 vengono rifiutati prima della prenotazione di un credito di recupero. Indicano rispettivamente input non valido, chiave assente o non valida, crediti insufficienti e limite di frequenza. Una richiesta a monte fallita libera il credito riservato, anche se la riconciliazione può restare in sospeso. Non descrivere ogni percorso di errore come rimborso immediato di un addebito precedente.
Se l’app perde la risposta dopo l’invio, potrebbe non sapere se il server abbia completato un recupero riuscito. Riprovare è un’altra richiesta, non una continuazione garantita gratuita. Registra l’incertezza, conserva la query ed evita una raffica automatica di tentativi. L’account espone i conteggi di richieste riuscite, in sospeso e rimborsate per la riconciliazione.
Imporre un tetto alla funzione
Ogni query consente pagine 1–100 e al massimo 100 record per richiesta. Sono limiti del servizio, non un invito a scaricare ogni pagina. L’app può scegliere un budget inferiore per una sessione di lettura interattiva e chiedere prima di recuperare altro. Rispetta pagination.has_more e il limite della finestra finale invece di cercare una pagina vuota con chiamate ripetute.
Non considerare la finestra potenziale di 10.000 record una resa garantita. Una risposta può essere vuota, i record possono mancare di campi e l’archivio non promette copertura completa. /v1/status è gratuito, ma non restituisce il saldo e non verifica la salute della ricerca. Anche i contatori locali richiedono riconciliazione: non provano che una richiesta persa fosse gratuita.
Rivedere le scelte realmente utili al lettore
Per il pannello escursionistico proposto possono bastare una prima pagina breve e un’azione Mostra altro intenzionale per confrontare riferimenti. Salva o riapri contenuti già presenti nell’app senza recuperarli nuovamente in silenzio. Se il lettore chiede esplicitamente un nuovo controllo di un elemento, spiega che è una nuova consultazione e gestisci un risultato indisponibile.
Usa le prove del tuo traffico per decidere se modificare limiti o presentazione. Non trasformare l’esempio di pianificazione in costi promessi per utente, tassi di mantenimento o benchmark prestazionali. Torna a /it/#field-notes per paginazione limitata e progettazione della lista locale.
