Rest API-referens för Azure Storage

Med REST-API:erna för Microsoft Azure Storage Services får du programmeringsbaserad åtkomst till tjänsterna Blob, Queue, Table och File i Azure, eller i utvecklingsmiljöer via lagringsemulatorn.

Alla lagringstjänster är tillgängliga via REST-API:er. Lagringstjänster kan nås från en tjänst som körs i Azure eller direkt via Internet från alla program som kan skicka en HTTP/HTTPS-begäran och ta emot ett HTTP/HTTPS-svar.

Viktigt

Azure Storage-tjänsterna stöder både HTTP och HTTPS. Att använda HTTPS rekommenderas dock starkt.

Lagringskonto

All åtkomst till lagringstjänster sker via lagringskontot. Lagringskontot är den högsta nivån i namnområdet för åtkomst till var och en av de grundläggande tjänsterna. Det är också grunden för auktorisering.

REST-API:erna för lagringstjänster exponerar lagringskontot som en resurs.

Blob-tjänst

Blob-tjänsten tillhandahåller lagring för entiteter, till exempel binära filer och textfiler. REST-API:et för blobtjänsten exponerar två resurser: containrar och blobar. En container är som en mapp som innehåller en uppsättning blobar. varje blob måste finnas i en container. Blobtjänsten definierar tre typer av blobar:

  • Blockblobar, som är optimerade för strömning. Den här typen av blob är den enda blobtypen som är tillgänglig med versioner före 2009-09-19.

  • Sidblobar, som är optimerade för slumpmässiga läs-/skrivåtgärder och som ger möjlighet att skriva till ett intervall med byte i en blob. Sidblobar är tillgängliga med version 2009-09-19 och senare. Dessa används främst för de VHD-filer som stöder AzureVM:erna.

  • Lägg till blobar som är optimerade endast för tilläggsåtgärder. Tilläggsblobar är endast tillgängliga med version 2015-02-21 och senare.

Containrar och blobar stöder användardefinierade metadata i form av namn/värde-par som anges som rubriker för en begärandeåtgärd.

Med hjälp av REST-API:et för Blob-tjänsten kan utvecklare skapa ett hierarkiskt namnområde som liknar ett filsystem. Blobnamn kan koda en hierarki med hjälp av en konfigurerbar sökvägsavgränsare. Blobnamnen MyGroup/MyBlob1 och MyGroup/MyBlob2 innebär till exempel en virtuell organisationsnivå för blobar. Uppräkningsåtgärden för blobbar stöder bläddring av den virtuella hierarkin på ett sätt som liknar en filsystems, så att du kan returnera en uppsättning blobar som är ordnade under en grupp. Du kan till exempel räkna upp alla blobar som är ordnade under MyGroup/.

En blockblob kan skapas på ett av två sätt. Du kan ladda upp en blob med en enda Put Blob-åtgärd eller ladda upp en blob som en uppsättning block med en Put Block-åtgärd och checka in blocken till en blob med en Put Block List-åtgärd .

Sidblobar skapas och initieras med en maximal storlek med ett anrop till Put Blob. Om du vill skriva innehåll till en sidblob anropar du put page-åtgärden .

Tilläggsblobar kan skapas genom att anropa Put Blob. En tilläggsblob som skapats med put blob-åtgärden innehåller inget innehåll. Om du vill skriva innehåll till en tilläggsblob lägger du till block i slutet av blobben genom att anropa åtgärden Lägg till block . Det går inte att uppdatera eller ta bort befintliga block. Varje block kan ha olika storlek, upp till högst 4 MiB. Den maximala storleken för en tilläggsblob är 195 GiB och en tilläggsblob får inte innehålla fler än 50 000 block.

Blobar stöder villkorsstyrda uppdateringsåtgärder som kan vara användbara för samtidighetskontroll och effektiv uppladdning.

Blobbar kan läsas genom att anropa åtgärden Hämta blob . En klient kan läsa hela bloben eller ett godtyckligt byteintervall.

Referens för Blob Service-API:et finns i REST API för Blob Service.

Kötjänst

Queue-tjänsten tillhandahåller tillförlitliga, beständiga meddelanden inom och mellan tjänster. REST-API:et för kötjänsten exponerar två resurser: köer och meddelanden.

Köer stöder användardefinierade metadata i form av namn/värde-par som anges som rubriker i en begärandeåtgärd.

Varje lagringskonto kan ha ett obegränsat antal meddelandeköer som namnges unikt i kontot. Varje meddelandekö kan innehålla ett obegränsat antal meddelanden. Den maximala storleken för ett meddelande är begränsad till 64 KiB för version 2011-08-18 och 8 KiB för tidigare versioner.

När ett meddelande läss från kön förväntas konsumenten bearbeta meddelandet och sedan ta bort det. När meddelandet har lästs görs det osynligt för andra användare under ett angivet intervall. Om meddelandet ännu inte har tagits bort när intervallet upphör att gälla återställs dess synlighet så att en annan konsument kan bearbeta det.

Mer information om kötjänsten finns i REST API för kötjänst.

Tabelltjänst

Tabelltjänsten tillhandahåller strukturerad lagring i form av tabeller. Tabelltjänsten stöder ett REST-API som implementerar OData-protokollet.

I ett lagringskonto kan en utvecklare skapa tabeller. Tabeller lagrar data som entiteter. En entitet är en samling namngivna egenskaper och deras värden, ungefär som en rad. Tabeller partitioneras för att stödja belastningsutjämning mellan lagringsnoder. Varje tabell har som sin första egenskap en partitionsnyckel som anger partitionen som en entitet tillhör. Den andra egenskapen är en radnyckel som identifierar en entitet inom en viss partition. Kombinationen av partitionsnyckeln och radnyckeln utgör en primärnyckel som identifierar varje entitet unikt i tabellen.

Tabelltjänsten framtvingar inget schema. En utvecklare kan välja att implementera och framtvinga ett schema på klientsidan. Mer information om tabelltjänsten finns i REST API för table service.

Filtjänst

SMB-protokollet (Server Message Block) är det föredragna filresursprotokollet som används lokalt idag. Med Microsoft Azure-filtjänsten kan kunderna utnyttja tillgängligheten och skalbarheten för Azures SMB (Cloud Infrastructure as a Service) utan att behöva skriva om SMB-klientprogram.

Azure File-tjänsten erbjuder också ett övertygande alternativ till traditionella LÖSNINGAR för direktansluten lagring (DAS) och SAN (Storage Area Network), som ofta är komplexa och dyra att installera, konfigurera och använda.

Filer som lagras i Azure File Service-resurser är tillgängliga via SMB-protokollet och även via REST-API:er. Filtjänsten erbjuder följande fyra resurser: lagringskonto, resurser, kataloger och filer. Resurser är ett sätt att organisera uppsättningar av filer och kan även monteras som en SMB-filresurs som finns i molnet.

Se även

REST APIQueue Service REST APITable Service REST APIFile Service REST API