Riferimento all'API REST di archiviazione di Azure
Le API REST per i servizi di archiviazione di Microsoft Azure offrono l'accesso a livello di programmazione ai servizi BLOB, Code, Tabelle e File in Azure o nell'ambiente di sviluppo tramite l'emulatore di archiviazione.
Tutti i servizi di archiviazione sono accessibili attraverso le API REST. I servizi di archiviazione sono accessibili da un servizio in esecuzione in Azure o direttamente su Internet da qualsiasi applicazione in grado di inviare una richiesta HTTP/HTTPS e di ricevere una risposta HTTP/HTTPS.
Importante
Il servizi di archiviazione di Azure supportano sia HTTP sia HTTPS, anche se l'utilizzo di HTTPS è vivamente consigliato.
Account di archiviazione
L'accesso ai servizi di archiviazione viene eseguito attraverso l'account di archiviazione. L'account di archiviazione è il livello più alto dello spazio dei nomi per accedere a ognuno dei servizi fondamentali. È anche la base per l'autorizzazione.
Le API REST per i servizi di archiviazione espongono l'account di archiviazione come risorsa.
Servizio BLOB
Il servizio Blob fornisce l'archiviazione per le entità, ad esempio i file binari e i file di testo. L'API REST per il servizio Blob espone due risorse: contenitori e Blob. Un contenitore è simile a una cartella contenente un set di BLOB; ogni BLOB deve risiedere in un contenitore. Il servizio BLOB definisce tre tipi di BLOB:
BLOB in blocchi, ottimizzati per il flusso. Questo tipo di Blob è l'unico tipo disponibile con le versioni precedenti alla 2009-09-19.
I BLOB in pagine, ottimizzati per le operazioni di lettura/scrittura casuali, consentono di scrivere su un intervallo di byte in un BLOB. I BLOB di pagine sono disponibili a partire dalla versione 2009-09-19. Questi vengono usati principalmente per i file VHD che eseguono il backup delle macchine virtuali di Azure.
Aggiungere BLOB, ottimizzati solo per le operazioni di accodamento. I BLOB di accodamento sono disponibili solo con la versione 2015-02-21 e versioni successive.
I contenitori e i Blob supportano i metadati definiti dall'utente sotto forma di coppie nome-valore specificate come intestazioni in un'operazione di richiesta.
Utilizzando l'API REST per il servizio Blob, gli sviluppatori possono creare uno spazio dei nomi gerarchico simile a un file system. I nomi dei Blob possono codificare una gerarchia utilizzando un separatore di percorso configurabile. Ad esempio, i nomi BLOB MyGroup/MyBlob1 e MyGroup/MyBlob2 implicano un livello virtuale di organizzazione per i BLOB. L'operazione di enumerazione per i Blob supporta l'attraversamento della gerarchia virtuale in un modo simile a quello di un file system, in modo che sia possibile restituire un set di Blob organizzati all'interno di un gruppo. Ad esempio, è possibile enumerare tutti i BLOB organizzati in MyGroup/.
Un Blob in blocchi può essere creato in uno di due modi. È possibile caricare un BLOB con un'unica operazione Put BLOB oppure caricare un BLOB come set di blocchi con un'operazione Put Block e eseguire il commit dei blocchi in un BLOB con un'operazione Put Block List .
I BLOB di pagine vengono creati e inizializzati con dimensioni massime con una chiamata a Put BLOB. Per scrivere contenuto in un BLOB di pagine, chiamare l'operazione Put Page .
È possibile creare BLOB di accodamento chiamando Put BLOB. Un BLOB di accodamento creato con l'operazione Put BLOB non include alcun contenuto. Per scrivere contenuto in un BLOB di accodamento, aggiungere blocchi alla fine del BLOB chiamando l'operazione Append Block . L'aggiornamento o l'eliminazione di blocchi esistenti non è supportato. Ogni blocco può essere di dimensioni diverse, fino a un massimo di 4 MiB. Le dimensioni massime per un BLOB di accodamento sono 195 GiB e un BLOB di accodamento non può includere più di 50.000 blocchi.
I Blob supportano le operazioni di aggiornamento condizionali, utili per il controllo della concorrenza e il caricamento efficiente.
I BLOB possono essere letti chiamando l'operazione Get BLOB . Un client può leggere l'intero Blob o un intervallo arbitrario di byte.
Per informazioni di riferimento sull'API del servizio BLOB, vedere API REST del servizio BLOB.
servizio di accodamento
Il servizio di accodamento fornisce un sistema di messaggistica persistente e affidabile tra i servizi e all'interno di essi. L'API REST per il servizio di accodamento espone due risorse: code e messaggi.
Le code supportano i metadati definiti dall'utente sotto forma di coppie nome-valore specificate come intestazioni in un'operazione di richiesta.
Ogni account di archiviazione può disporre di un numero illimitato di code di messaggi denominate in modo univoco all'interno dell'account. Ogni coda di messaggi può contenere un numero illimitato di messaggi. Le dimensioni massime per un messaggio sono limitate a 64 KiB per la versione 2011-08-18 e 8 KiB per le versioni precedenti.
Quando un messaggio viene letto dalla coda, il messaggio viene elaborato ed eliminato dal consumer. Dopo essere stato letto, il messaggio viene reso invisibile agli altri consumer per un intervallo specificato. Se il messaggio non è ancora stato eliminato alla scadenza dell'intervallo, viene reso nuovamente visibile in modo che possa essere elaborato da un altro consumer.
Per altre informazioni sul servizio Code, vedere API REST del servizio code.
Servizio tabelle
Il servizio tabelle fornisce un'archiviazione strutturata sotto forma di tabelle. Il servizio Tabelle supporta un'API REST che implementa il protocollo OData.
All'interno di un account di archiviazione, uno sviluppatore può creare tabelle. Nelle tabelle i dati sono archiviati come entità. Un'entità è una raccolta di proprietà denominate e dei rispettivi valori ed è simile a una riga. Le tabelle sono partizionate per supportare il bilanciamento del carico tra i nodi di archiviazione. Come prima proprietà ogni tabella include una chiave di partizione che specifica la partizione a cui appartiene l'entità. La seconda proprietà è una chiave di riga che identifica un'entità all'interno di una partizione specificata. La combinazione della chiave di partizione e della chiave di riga rappresenta una chiave primaria che identifica ogni entità in modo univoco all'interno della tabella.
Tramite il servizio tabelle non viene applicato alcuno schema. Uno sviluppatore può scegliere di implementare e applicare uno schema sul lato client. Per altre informazioni sul servizio tabelle, vedere API REST del servizio tabelle.
Servizio file
Il protocollo SMB (Server Message Block) è il protocollo di condivisione file preferito usato in locale. Il servizio file di Microsoft Azure consente ai clienti di sfruttare la disponibilità e la scalabilità di SMB dell'infrastruttura del cloud di Azure distribuita come servizio senza dover riscrivere le applicazioni client SMB.
Il servizio file di Azure inoltre fornisce una valida alternativa alle tradizionali soluzioni basate su archiviazione diretta (DAS, Direct Attached Storage) e su rete di archiviazione (SAN, Storage Area Network), che spesso sono complesse e costose da installare, configurare e utilizzare.
I file archiviati nelle condivisioni del servizio file di Azure sono accessibili tramite il protocollo SMB, nonché tramite le API REST. Il servizio File offre le quattro risorse seguenti: account di archiviazione, condivisioni, directory e file. Le condivisioni consentono di organizzare set di file e possono anche essere montate come condivisione file SMB ospitata nel cloud.
Vedi anche
API REST del servizio REST del servizio API REST del servizio API REST del servizio BLOB