Informations de référence sur l’API REST stockage Azure

Les API REST pour les services de stockage Microsoft Azure offrent un accès par programme aux services BLOB, de File d’attente, de Table et de Fichiers dans Azure, ou dans l’environnement de développement via l’émulateur de stockage.

Tous les services de stockage sont accessibles via les API REST. Les services de stockage sont accessibles au sein d'un service qui exécute Azure, ou directement via Internet à partir d'une application qui peut envoyer une demande HTTP/HTTPS et recevoir une réponse HTTP/HTTPS.

Compte de stockage

Tous les accès aux services de stockage ont lieu via le compte de stockage. Le compte de stockage est le niveau le plus élevé de l'espace de noms pour accéder à chacun des services principaux. C’est également la base de l’autorisation.

Les API REST pour les services de stockage exposent le compte de stockage en tant que ressource.

Service blob

Le service BLOB fournit le stockage pour les entités, telles que les fichiers binaires et les fichiers texte. L'API REST pour le service BLOB expose deux ressources : conteneurs et objets blob. Un conteneur est semblable à un dossier, contenant un ensemble d’objets blob ; chaque objet blob doit résider dans un conteneur. Le service Blob définit trois types d’objets blob :

• les objets blob de blocs, qui sont optimisés pour la diffusion ; Ce type d'objet blob est le seul type d'objet blob disponible avec les versions antérieures au 19/09/2009.

• les objets blob de pages, qui sont optimisés pour des opérations de lecture/écriture aléatoires et qui permettent d'écrire dans une plage d'octets d'un objet blob. Les objets blob de pages sont disponibles uniquement à partir de la version 2009-09-19. Ils sont principalement utilisés pour les fichiers de disque dur virtuel qui sauvegardent les machines virtuelles Azure.

• Objets blob d’ajout, qui sont optimisés pour les opérations d’ajout uniquement. Les objets blob d’ajout sont disponibles uniquement avec la version 2015-02-21 et ultérieure.

Les conteneurs et les objets blob prennent en charge les métadonnées définies par l'utilisateur sous la forme de paires nom-valeur spécifiées en tant qu'en-têtes dans une opération de demande.

En utilisant l'API REST pour le service BLOB, les développeurs peuvent créer un espace de noms hiérarchique semblable à un système de fichiers. Les noms d'objet blob peuvent encoder une hiérarchie à l'aide d'un séparateur de chemin configurable. Par exemple, les noms d'objet blob MyGroup/MyBlob1 et MyGroup/MyBlob2 impliquent un niveau virtuel d'organisation pour les objets blob. L'opération d'énumération pour les objets blob prend en charge le parcours de la hiérarchie virtuelle d'une façon semblable à celle d'un système de fichiers, afin que vous puissiez renvoyer un ensemble d'objets blob organisés sous un groupe. Par exemple, vous pouvez énumérer tous les objets blob organisés sous MyGroup/.

Un objet blob de blocs peut être créé de deux façons. Vous pouvez charger un objet blob avec une seule opération Put Blob , ou vous pouvez charger un objet blob en tant qu’ensemble de blocs avec une opération Put Block et valider les blocs dans un objet blob avec une opération Put Block List .

Les objets blob de pages sont créés et initialisés avec une taille maximale avec un appel à Put Blob. Pour écrire du contenu dans un objet blob de pages, vous appelez l’opération Put Page .

Vous pouvez créer des objets blob d’ajout en appelant Put Blob. Un objet blob d’ajout créé avec l’opération Put Blob n’inclut aucun contenu. Pour écrire du contenu dans un objet blob d’ajout, vous ajoutez des blocs à la fin de l’objet blob en appelant l’opération Append Block . La mise à jour ou la suppression de blocs existants ne sont pas prises en charge. Chaque bloc peut être de taille différente, jusqu’à un maximum de 4 Mio. La taille maximale d’un objet blob d’ajout est de 195 Gio, et un objet blob d’ajout ne peut pas inclure plus de 50 000 blocs.

Les objets blob prennent en charge les opérations de mise à jour conditionnelles pouvant être utiles pour le contrôle concurrentiel et un téléchargement efficace.

Les objets blob peuvent être lus en appelant l’opération Obtenir l’objet blob . Un client peut lire l'intégralité de l'objet blob ou une plage aléatoire d'octets.

Pour obtenir des informations de référence sur l’API du service Blob, consultez API REST du service Blob.

Service de File d'attente

Le service de File d'attente fournit une messagerie fiable et persistante au sein et entre les services. L'API REST pour le service de File d'attente expose deux ressources : les files d'attente et les messages.

Les files d'attente prennent en charge les métadonnées définies par l'utilisateur sous la forme de paires nom-valeur spécifiées en tant qu'en-têtes dans une opération de demande.

Chaque compte de stockage peut avoir un nombre illimité de files d'attente de messages qui sont nommées uniquement dans le compte. Chaque file d'attente de messages peut contenir un nombre illimité de messages. La taille maximale d’un message est limitée à 64 Kio pour la version 2011-08-18 et à 8 Kio pour les versions précédentes.

Lorsqu'un message est lu à partir de la file d'attente, le consommateur doit traiter le message, puis le supprimer. Une fois le message lu, il est rendu invisible aux autres consommateurs pendant un intervalle donné. Si le message n'a pas encore été supprimé au moment de l'expiration de l'intervalle, sa visibilité est restaurée, afin qu'un autre consommateur puisse le traiter.

Pour plus d’informations sur le service file d’attente, consultez API REST du service de file d’attente.

Service de Table

Le service de Table fournit un stockage structuré sous la forme de tables. Le service Table prend en charge une API REST qui implémente le protocole OData.

Dans un compte de stockage, un développeur peut créer des tables. Les tables stockent les données sous forme d'entités. Une entité est une collection de propriétés nommées et de leurs valeurs, semblable à une ligne. Les tables sont partitionnées pour prendre en charge l'équilibrage de charge entre les nœuds de stockage. Chaque table utilise en tant que première propriété une clé de partition qui spécifie la partition à laquelle appartient une entité. La deuxième propriété est une clé de ligne qui identifie une entité au sein d'une partition donnée. La combinaison de la clé de partition et de la clé de ligne forme une clé primaire qui identifie chaque entité de façon unique dans la table.

Le service de Table ne met en œuvre aucun schéma. Un développeur peut choisir d'implémenter et d'appliquer un schéma côté client. Pour plus d’informations sur le service Table, consultez API REST du service de table.

Service de fichiers

Le protocole SMB (Server Message Block) est le protocole de partage de fichiers préféré utilisé localement aujourd’hui. Le service de Fichier Microsoft Azure permet aux utilisateurs de bénéficier de la disponibilité et de l'extensibilité de l'infrastructure cloud d'Azure en tant que SMB de service (IaaS) sans avoir à réécrire le code des applications clientes SMB.

Le service de Fichier Azure constitue également une alternative intéressante aux solutions traditionnelles DAS (stockage en attachement direct) et SAN (réseau de zone de stockage), dont l'installation, la configuration et l'exploitation sont souvent plus compliquées et coûteuses.

Les fichiers partagés dans le service Fichier Azure sont accessibles via le protocole SMP ou les API REST. Le service De fichiers offre les quatre ressources suivantes : le compte de stockage, les partages, les répertoires et les fichiers. Les partages offrent un moyen d'organiser des ensembles de fichiers. Ils peuvent également être montés en tant que partage de fichiers SMB hébergé dans le cloud.

Voir aussi

API De file d’attente de l’API REST du service De table REST du service d’API Blob Service API File Service API REST