Les conteneurs regroupent plusieurs BLOB et émulent le mode de stockage des fichiers par les dossiers.
Les conteneurs sont limités au contexte des comptes et, à la différence d’autres types de stockage Azure, ils peuvent être désignés publiquement comment étant en lecture seule ou privés lorsque vous créez le conteneur avec des requêtes REST (Representational State Transfer) ou du code.NET.
Les conteneurs privés nécessitent une chaîne d’autorisation AccountSharedKey 256 bits (SHA256), que vous copiez à partir des zones de clé d’accès primaire ou secondaire (Primary/Secondary Access Key) au niveau de la page nom_service_stockage Summary. Vous pouvez ajouter un maximum de 8 ko de métadonnées à un conteneur sous la forme d’une paire attribut/valeur. Le stockage Azure propose une API REST, de sorte que quiconque connaît l’URI (Uniform Resource Identifier) pour votre service de stockage public (http://nom_service_stockage.blob.core .windows.net) peut lister ses conteneurs avec une simple requête HTTP GET, telle que http://oakleaf2.blob. core.windows.net/?comp=list. Le renvoi d’une liste de BLOB dans le conteneur oakleafblobs utilise une syntaxe avec le nom de BLOB préfixé à la chaîne de requête http://oakleaf2.blob.core.windows.net/oakleafblobs?comp= list. Le Request Builder de Fiddler2 Web Debugging Proxy facilite l’écriture et l’exécution de requêtes HTTP RESTful.
La taille maximale d’un BLOB Azure est de 50 Go dans la CTP de mai 2009, mais le BLOB le plus volumineux téléchargeable en une seule opération PUT est de 64 Go. La création de BLOB relativement volumineux nécessite le téléchargement (upload) et l’adjonction de blocs d’une taille maximum de 4 Mo. Pour gérer des téléchargements ininter – rompus, chaque bloc a un numéro de séquence, de sorte qu’ils peuvent être ajoutés dans n’importe quel ordre. Il est possible de mettre à jour les BLOB en téléchargeant de nouveaux blocs qui remplacent les versions précédentes. Azure réplique toutes les données de BLOB au moins trois pour des raisons de durabilité. Une cohérence forte fait en sorte qu’un BLOB est accessible immédiatement après son téléchargement ou sa modification. Les BLOB sont limités au contexte des conteneurs, de sorte qu’une requête GET destinée à retourner un BLOB graphique spécifique d’un conteneur oakleafblobs public aura la forme suivante : http://oakle af2.blob.core.windows.net/oakleafblobs/nomblob.png.
Les requêtes HTTP REST utilisent PUT BlobURI pour insérer un nouveau BLOB ou remplacer un BLOB nommé BlobURI, avec la même syntaxe que pour les requêtes GET. GET BlobURI peut retourner une plage d’octets avec l’opération HTTP GET standard et l’en-tête d’entité Content Range. L’API REST gère également les requêtes HEAD pour déterminer l’existence d’un conteneur ou BLOB sans retourner ses données utiles. Les requêtes DELETE se servent des mêmes URI que PUT, GET et HEAD. PUT BlobURI, GET BlockListURI et PUT BlockListURI utilisent un modèle d’adressage similaire. La section « Blob Storage API » du Windows Azure SDK contient plus d’informations sur l’APIREST concernant le stockage de BLOB.
Dans le contexte actuel, l'expérience client est un levier clé de réussite. Pour rester compétitives, les entreprises doivent adopter des stratégies CX audacieuses, en s'appuyant sur le cloud, le digital et l'IA. Alors quelles stratégies mettre en place pour garder une longueur d’avance ?
