Gestisci i limiti di richieste dell'API dosya

dosya applica più limiti. Il traffico autenticato generale e di caricamento è limitato a 300 richieste al minuto per utente, gli elenchi a 600 al minuto e il traffico IP autenticato a 600 al minuto, salvo l’eccezione per la sincronizzazione desktop. Una chiave API può avere anche una propria quota di richieste al minuto.

Prima di iniziare

• Assicurati che il client conservi lo stato e le intestazioni della risposta; un parser JSON da solo perde il segnale per riprovare.
• Decidi se è sicuro ripetere la richiesta. Le letture sono di solito sicure; le modifiche richiedono una ricevuta specifica della route o un contratto di idempotenza.
• Mantieni la concorrenza sotto il limite documentato invece di usare i tentativi ripetuti per controllare il flusso.

Passaggi

1. Controlla ogni risposta per X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Reset. Il limitatore generale include queste intestazioni anche nelle richieste riuscite.
2. Se lo stato è 429, leggi Retry-After prima di analizzare il corpo. Un rifiuto per chiave può indicare This API key has exceeded its requests-per-minute limit e garantisce solo la presenza di Retry-After.
3. Attendi il ritardo indicato dal server, poi aggiungi una piccola variazione casuale per evitare che i processi paralleli ripartano insieme. Limita un ritardo malformato o eccessivo in base alla scadenza del processo.
4. Dopo l’attesa ripeti una lettura o un caricamento idempotente. Per uno spostamento, una rinomina, un’operazione nel cestino o un’altra modifica dall’esito incerto, verifica lo stato remoto invece di ripeterla automaticamente.
5. Limita il numero di tentativi. La CLI dosya usa al massimo tre tentativi dopo la richiesta iniziale, una sequenza alternativa di 1, 3 e 8 secondi e limita a 60 secondi un valore Retry-After valido.
6. Registra route, stato, numero di tentativo e durata dell’attesa senza registrare credenziali. Riduci la concorrenza se i 429 si ripetono dopo un’intera finestra di ripristino.

Risultato previsto

Il client attende invece di riprovare senza sosta, completa la richiesta quando torna disponibile capacità e si ferma quando esaurisce il numero massimo di tentativi. L’automazione distingue la quota per chiave dal limite generale per utente o IP senza presumere intestazioni identiche.

Risoluzione dei problemi

Retry-After è assente. Usa un ritardo esponenziale prudente con variazione casuale; la sequenza alternativa della CLI è 1, 3 e poi 8 secondi.

Una modifica è scaduta prima di ricevere lo stato. Leggi la risorsa o l’endpoint della ricevuta. Ripeti l’operazione solo se è documentata come idempotente.

Il 429 continua dopo il ripristino. Riduci la concorrenza e controlla la quota di richieste al minuto configurata per la chiave API. Una nuova chiave non rimuove la protezione per utente o IP.

Guide correlate

• Guida rapida all’API REST
• Esamina le consegne dei webhook