Stabilire chi decide e quale operazione protegge
Il punto di partenza è distinguere le responsabilità. Reddit Gateway verifica la chiave per il recupero protetto; la tua applicazione decide quali suoi utenti possono richiedere quei dati. L’archivio non offre per questo un sistema di ruoli, gruppi o autorizzazioni per i tuoi progetti. Se servono approvazioni interne o limiti di spesa per utente, progettali nella tua piattaforma. Indica chiaramente quale azione può generare una richiesta a pagamento e chi può avviarla.
Il percorso pubblico /v1/status può alimentare una voce separata sulla risposta HTTP. Non richiede una chiave e non consuma crediti, ma non verifica il motore di ricerca. Non usarlo come autorizzazione per un utente o controllo del saldo. Sono passaggi distinti: decisione locale sui permessi, recupero protetto con chiave e gestione dell’account nel pannello della pagina Ottieni una chiave API. Una risposta di stato non sostituisce nessuno degli altri due.
Conserva la chiave sul tuo server ed escludila dal codice inviato al browser, dai repository pubblici, dai messaggi di errore e dai registri. Per il recupero sono supportati X-API-Key: <key> e Authorization: Bearer <key>. La sessione del pannello usa invece un cookie Secure HttpOnly. Gli identificatori di utente e fattura conservati localmente dal pannello non sostituiscono la chiave. Questa separazione aiuta a progettare il flusso, ma richiede comunque controlli sulla tua implementazione.
Limitare gli ingressi e interpretare la risposta
Una possibile misura nella tua applicazione è fissare il nome host e una lista dei percorsi consentiti, evitando che l’utente inoltri un indirizzo arbitrario. Per l’esempio usa https://api.redditgateway.com/v1/search?q=database&subreddit=backend&limit=3: q cerca database, subreddit sceglie backend e limit limita la pagina a tre record. Sono parametri di ricerca storica, non la promessa di trovare una discussione specifica. Consulta la documentazione per scegliere il percorso e i filtri adatti a ogni operazione.
Controlla lo stato HTTP e il formato ricevuto prima di segnare una pagina come elaborata. Una lista data vuota in una risposta riuscita è un risultato valido; non va confusa con un errore. Se il tuo processo lo richiede, conserva il contenuto effettivamente ricevuto insieme ai parametri usati. Decidi quali metadati servono per diagnosticare problemi, escludendo dai registri la chiave e le intestazioni di autenticazione. La conservazione locale è una scelta della tua applicazione.
Le ricerche /v1/search, /v1/posts e /v1/comments ammettono i filtri documentati. from e to usano YYYY-MM-DD e si applicano a created_utc; il giorno finale è incluso interamente in UTC. min_score filtra senza ordinare. /v1/item richiede id e restituisce un singolo record, non un albero ricorsivo. /v1/subreddits usa prefix e limit. La presenza di parent_id o link_id nei dati non introduce filtri server aggiuntivi con quei nomi.
Controllare avanzamento, errori e consumo
Imposta un limite esplicito al ciclo locale di paginazione: page e limit vanno da 1 a 100. relation=eq indica un totale esatto per la query, gte un limite inferiore e unknown l’assenza di un totale affidabile, che può essere nullo. Nessuno di questi valori certifica la copertura dell’archivio. Conserva la pagina ricevuta prima di avanzare il tuo cursore locale. Suddividere per intervalli di tempo non garantisce completezza, assenza di duplicati o risultati immutabili.
Distingui le cause degli errori: con 400 correggi i parametri, con 401 verifica chiave e intestazione e con 402 controlla saldo ed eventuale ricarica nel pannello. Per 429 puoi prevedere tentativi limitati con pause crescenti, senza promettere che il successivo avrà esito positivo. Non dedurre da questo codice una particolare classe di servizio. I controlli di rete sull’assegnazione del credito di prova sono un meccanismo distinto. La pagina Prezzi descrive il costo dei recuperi riusciti.
Considera ogni ripetizione riuscita come un nuovo recupero a pagamento, anche con risultati vuoti. Le richieste non valide non sono addebitate; gli errori a monte restituiscono la prenotazione. Un timeout del client non dimostra però che il server non abbia già completato e addebitato la richiesta. La rigenerazione nel pannello autenticato richiede la password e invalida immediatamente la vecchia chiave. Aggiorna quindi consapevolmente le configurazioni server interessate e verifica poi il percorso protetto con la nuova credenziale.
