Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Importante
Questa funzionalità è in versione beta. Per utilizzarlo, un amministratore dello spazio di lavoro deve attivare Files API V3 con supporto per il caricamento di file di grandi dimensioni dalla pagina delle anteprime. Vedere Gestire le anteprime di Azure Databricks.
Le richieste condizionali ti permettono di far dipendere un'operazione dallo stato corrente del file di destinazione, quindi la richiesta ha effetto solo se il file si trova nello stato che ti aspetti. Questo ti permette di evitare trasferimenti sprecati, di evitare aggiornamenti persi da parte di autori concorrenti e di creare o cancellare file in modo sicuro.
Files API 3.0 supporta i quattro standard intestazioni condizionali HTTP provenienti dall'RFC 9110.
| Header | Confronta rispetto a | Onorato il |
|---|---|---|
If-Match |
Del file ETag |
Leggere, scrivere ed eliminare |
If-None-Match |
Del file ETag |
Legge e scrive |
If-Modified-Since |
L'ora del file Last-Modified |
Sola lettura |
If-Unmodified-Since |
L'ora del file Last-Modified |
Sola lettura |
If-Modified-Since e If-Unmodified-Since si applicano solo alle operazioni di lettura (GET e HEAD). Non sono supportate né in upload né in fase di eliminazione.
Quando la condizione non è soddisfatta, il server non esegue l'operazione e restituisce uno dei seguenti stati:
-
304 Not Modified, quando una richiestaGEToHEADconIf-None-MatchoIf-Modified-Sincefallisce. Conferma che la tua copia cache è ancora valida, quindi non c'è bisogno di inviare di nuovo il file. -
412 Precondition Failed, quando qualsiasi altra condizione fallisce. L’operazione di lettura, caricamento o cancellazione non viene eseguita.
Validatori: ETag e Last-Modified
Una richiesta condizionale confronta un validator che fornisci con quello attuale del file. L'API Files restituisce entrambi i validatori come intestazioni di risposta, così puoi catturarli e usarli in una richiesta successiva:
-
ETag: un identificatore opaco per il contenuto attuale del file. Memorizza il valore esatto restituito dal server, comprese le virgolette circostanti, e invialo invariato. Non eseguire il parsing di essa o costruirla. -
Last-Modified: la data dell'ultima modifica del file, come data HTTP.
Entrambi i validatori vengono restituiti nelle risposte GET e HEAD.
ETag viene inoltre restituito su PUT e nella risposta multipart complete-upload.
Last-Modified ha una precisione di un secondo.
If-Modified-Since e If-Unmodified-Since non possono rilevare diversi cambiamenti fatti nello stesso secondo, quindi non affidarti a loro per un controllo preciso della concorrenza. Usare ETag con If-Match o If-None-Match invece.
Letture condizionali
Su GET e HEAD, tutte e quattro le intestazioni condizionali vengono rispettate. L'uso più comune è la rivalidazione della cache: hai una copia precedentemente scaricata e vuoi che il server invii di nuovo i byte solo se sono stati modificati.
Invia If-None-Match con la ETag della copia memorizzata nella cache, o If-Modified-Since con l'ultima volta che l'hai recuperata. Se il file rimane invariato, il server restituisce 304 Not Modified senza corpo e tu continui a usare la copia nella cache. Se è cambiato, il server torna 200 OK con i nuovi contenuti.
Per rivalidare un file memorizzato nella cache, invia il relativo ETag e scarica il corpo solo se il file è cambiato:
GET /api/3.0/fs/files/Volumes/main/default/reports/report.csv
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
304 Not Modified
Gli altri due header di read affermano la condizione opposta.
If-Match restituisce il file solo se il suo ETag corrisponde ancora, e altrimenti restituisce 412.
If-Unmodified-Since lo restituisce solo se il file non è cambiato dall'ora specificata, e altrimenti restituisce 412.
Puoi inviare al massimo due header condizionali in un'operazione di lettura. Le richieste che superano il limite non sono supportate. Quando ne invii due, la loro precedenza segue la RFC 9110.
operazioni di scrittura condizionate
Su PUT, puoi usare If-None-Match e If-Match per tutelare un caricamento rispetto allo stato corrente del file:
-
If-None-Match: *salva il file solo se non esiste già. Questo garantisce che il caricamento non sovrascriva accidentalmente un altro upload, facendo perdere i suoi dati, il che è una variante del problema dell'aggiornamento perso. Se un file esiste già nel percorso, la richiesta restituisce412 Precondition Failed. -
If-Match: <etag>Previene il problema dell'aggiornamento perso. Controlla che il caricamento non sovrascriva un'altra modifica apportata da quando hai recuperato il file. Il caricamento ha successo solo se ilETagcorrente del file corrisponde a quello che fornisci. Altrimenti, la richiesta restituisce412 Precondition Failed. Se non esiste alcun file sul percorso, la richiesta restituisce404.
Per creare un file solo se non esiste già, invia If-None-Match: *:
PUT /api/3.0/fs/files/Volumes/main/default/reports/report.csv
If-None-Match: *
Content-Type: application/octet-stream
<binary data>
200 OK
Per sovrascrivere un file solo se è ancora la versione che hai recuperato l'ultima volta, invia il suo ETag con If-Match:
PUT /api/3.0/fs/files/Volumes/main/default/reports/report.csv
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Content-Type: application/octet-stream
<binary data>
200 OK
Le seguenti forme non sono supportate su PUT: un elenco di ETag, If-Match: *, If-None-Match con uno specifico ETag, If-Modified-Since e If-Unmodified-Since.
Per un caricamento multiparte, invia l'intestazione condizionale nella chiamata initiate-upload. Files API lo memorizza e lo valuta al completamento del caricamento, quindi la condizione si applica al file assemblato finale. Puoi usare le stesse due intestazioni come su PUT: If-None-Match: * e If-Match: <etag>. Le intestazioni condizionali nella chiamata complete-upload o abort-upload stessa non sono supportate.
Cancellazioni condizionali
DELETE è idempotente. L'eliminazione di un file che non esiste restituisce comunque 204 No Content. Questo rende la pulizia semplice, ma un semplice DELETE non può dirti se hai rimosso la versione che intendevi. Per rendere un'eliminazione condizionale, invia If-Match:
-
If-Match: <etag>elimina il file solo se il suoETagcorrente corrisponde a quello che fornisci. Se un altro utente ha modificato il file dopo averlo recuperato, la richiesta restituisce412 Precondition Failedinvece di rimuovere la sua modifica. Se il file non esiste più, la richiesta restituisce404. -
If-Match: *Cancella il file solo se esiste. La richiesta restituisce204se il file esisteva e404se no.
DELETE /api/3.0/fs/files/Volumes/main/default/reports/report.csv
If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
204 No Content
Le restanti intestazioni condizionali (If-None-Match, If-Unmodified-Since e DELETE) non sono supportate su If-Modified-Since.