Esporta (0) Stampa
Espandi tutto

Informazioni di riferimento sulle API REST dei servizi di archiviazione

Aggiornamento: febbraio 2014

Le API REST per i servizi di archiviazione di Microsoft® Azure™ offrono agli sviluppatori l'accesso a livello di codice ai servizi Blob, di accodamento, tabelle e file in Microsoft Azure o nell'ambiente di sviluppo, attraverso 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 Microsoft Azure o direttamente su Internet da qualsiasi applicazione in grado di inviare una richiesta HTTP/HTTPS e di ricevere una risposta HTTP/HTTPS.

ImportantImportante
Il servizi di archiviazione di Azure supportano sia HTTP sia HTTPS, anche se è consigliabile utilizzare HTTP.

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'autenticazione.

Le API REST per i servizi di archiviazione espongono l'account di archiviazione come risorsa.

Per creare e gestire un account di archiviazione, vedere Gestire account, sottoscrizioni e ruoli amministrativi.

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 è un set di Blob; ogni Blob deve appartenere a un contenitore. Il servizio Blob definisce due 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 solo con la versione 2009-09-19.

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. I nomi dei Blob MyGroup/MyBlob1 e MyGroup/MyBlob2, ad esempio, 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. I Blob in blocchi di dimensioni inferiori o uguali a 64 MB possono essere caricati chiamando l'operazione Put Blob. I Blob in blocchi di dimensioni superiori a 64 MB devono essere caricati come set di blocchi, ognuno dei quali deve essere di dimensioni inferiori o uguali a 4 MB. Un set di blocchi caricati correttamente può essere assemblato in un ordine specificato in un Blob contiguo chiamando Put Block List. Le dimensioni massime attualmente supportate per un Blob in blocchi sono 200 GB.

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. Le dimensioni massime attualmente supportate per un Blob di pagine sono 1 GB.

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 il riferimento all'API del servizio Blob, vedere API REST del servizio Blob.

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 KB per la versione 2011-08-18 e a 8 KB 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 di accodamento, vedere API REST del servizio di accodamento.

Il servizio tabelle fornisce un'archiviazione strutturata sotto forma di tabelle. Il servizio tabelle supporta un'API REST mediante la quale viene implementato il protocollo OData.

In un account di archiviazione, uno sviluppatore può creare tabelle denominate. 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.

Server Message Block (SMB) attualmente è il protocollo di condivisione file preferito per l'utilizzo 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 seguenti quattro risorse: 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.

Vedere anche

Mostra:
© 2014 Microsoft