VENTES: 1-800-867-1389

Référence de l'API REST des services de stockage

Mis à jour: février 2014

Les API REST pour les services de stockage Windows® Azure™ fournissent un accès par programmation aux services BLOB, de File d'attente, de Table et de Fichier dans Windows 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 Windows Azure, ou directement via Internet à partir d'une application qui peut envoyer une demande HTTP/HTTPS et recevoir une réponse HTTP/HTTPS.

ImportantImportant
Les services de stockage Windows Azure prennent en charge les protocoles HTTP et HTTPS. Toutefois, nous vous conseillons d'utiliser le protocole HTTPS.

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. Il sert également de base à l'authentification.

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

Pour créer et gérer un compte de stockage, consultez Gérer des comptes, des abonnements et des rôles d'administrateur.

Le service BLOB fournit le stockage pour les entités, telles que les fichiers binaires et les fichiers texte. L'API REST du service BLOB expose deux ressources : conteneurs et objets blobs. Un conteneur est un ensemble d'objets blob ; chaque objet blob doit appartenir à un conteneur. Le service BLOB définit deux 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 avec la version du 19/09/2009.

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 retourner 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. Les objets blob de blocs d'une taille inférieure ou égale à 64 Mo peuvent être téléchargés en appelant l'opération Put Blob. Les objets blob de blocs supérieurs à 64 Mo doivent être téléchargés sous forme d'ensemble de blocs, devant être inférieurs ou égaux à 4 Mo. Un ensemble de blocs correctement téléchargés peut être assemblé dans un ordre spécifié dans un unique objet blob contigu en appelant Put Block List. La taille maximale actuellement prise en charge pour un objet blob de blocs est de 200 Go.

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. La taille maximale actuellement prise en charge pour un objet blob de pages est de 1 To.

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 Get Blob. Un client peut lire l'intégralité de l'objet blob ou une plage aléatoire d'octets.

Pour les informations de référence de l'API du service BLOB, consultez API REST du service BLOB.

Le service de File d'attente fournit une messagerie fiable et persistante au sein et entre les services. L'API REST du service de File d'attente expose deux ressources : files d'attente et 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 pour un message est limitée à 64 Ko pour la version du 18/08/2011 et à 8 Ko 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 de File d'attente, consultez API REST du service de File d'attente.

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

Au sein d'un compte de stockage, un développeur peut créer des tables nommées. 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 de Table, consultez API REST du service de Table.

Le protocole SMB (Server Message Block) est actuellement le protocole de partage de fichiers le plus utilisé sur site. 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 Fichier fournit 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

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft