Referencia de la API REST de Azure Storage
Las API REST de los servicios de almacenamiento de Microsoft Azure ofrecen acceso programático a los servicios de Blob, Cola, Tabla y Archivo en Azure o en el entorno de desarrollo mediante el emulador de almacenamiento.
Se puede tener acceso a todos los servicios de almacenamiento a través de las API de REST. Se puede obtener acceso a los servicios de almacenamiento desde un servicio que se ejecute en Azure, o directamente a través de Internet desde cualquier aplicación que pueda enviar una solicitud HTTP/HTTPS y recibir una respuesta HTTP/HTTPS.
Importante
Los servicios de almacenamiento de Azure admiten HTTP y HTTPS; sin embargo, se recomienda encarecidamente utilizar HTTPS.
Cuenta de almacenamiento
Todo el acceso a los servicios de almacenamiento se realiza a través de la cuenta de almacenamiento. La cuenta de almacenamiento es el nivel superior del espacio de nombres para tener acceso a cada uno de los servicios fundamentales. También es la base para la autorización.
Las API de REST para los servicios de almacenamiento exponen la cuenta de almacenamiento como un recurso.
Blob Service
El servicio Blob proporciona almacenamiento para entidades, como archivos binarios y archivos de texto. La API de REST para Blob service expone dos recursos: contenedores y blobs. Un contenedor es como una carpeta, que contiene un conjunto de blobs; cada blob debe residir en un contenedor. Blob service define tres tipos de blobs:
Blobs en bloques, que están optimizados para la transmisión por secuencias. Este tipo de blob es el único disponible con las versiones anteriores a 2009-09-19.
Blobs en páginas, que están optimizados para las operaciones de lectura/escritura aleatorias y proporcionan la posibilidad de escribir en un intervalo de bytes de un blob. Los blobs de página están disponibles con la versión 19-09-2009 y versiones posteriores. Estos se usan principalmente para los archivos VHD que respaldan las máquinas virtuales de Azure.
Blobs en anexos, que solo están optimizados para operaciones de anexión. Los blobs en anexos solo están disponibles con la versión 2015-02-21 y posteriores.
Los contenedores y los blobs admiten metadatos definidos por el usuario en forma de pares nombre-valor especificados como encabezados en una operación de solicitud.
Mediante la API de REST para Blob service, los desarrolladores pueden crear un espacio de nombres jerárquico similar a un sistema de archivos. Los nombres de blob pueden codificar una jerarquía utilizando un separador de ruta de acceso configurable. Por ejemplo, los nombres de blob MyGroup/MyBlob1 y MyGroup/MyBlob2 implican un nivel virtual de organización para blobs. La operación de enumeración para los blobs permite recorrer la jerarquía virtual de forma similar a la de un sistema de archivos, de forma que se pueda devolver un conjunto de blobs organizados debajo de un grupo. Por ejemplo, puede enumerar todos los blobs organizados en MyGroup/.
Existen dos maneras de crear un blob en bloques. Puede cargar un blob con una sola operación Put Blob o puede cargar un blob como un conjunto de bloques con una operación Put Block y confirmar los bloques en un blob con una operación Put Block List .
Los blobs en páginas se crean e inicializan con un tamaño máximo con una llamada a Put Blob. Para escribir contenido en un blob en páginas, llame a la operación Put Page .
Los blobs en anexos se pueden crear mediante una llamada a Put Blob. Un blob en anexos creado con la operación Put Blob no incluye ningún contenido. Para escribir contenido en un blob en anexos, agregue bloques al final del blob llamando a la operación Append Block . No se admite la actualización o eliminación de bloques existentes. Cada bloque puede tener un tamaño diferente, hasta un máximo de 4 MiB. El tamaño máximo de un blob en anexos es de 195 GiB y un blob en anexos no puede incluir más de 50 000 bloques.
Los blobs admiten operaciones de actualización condicionales que pueden ser útiles para el control de simultaneidad y la carga eficaz.
Los blobs se pueden leer llamando a la operación Obtener blob . Un cliente puede leer el blob completo o un intervalo arbitrario de bytes.
Para obtener la referencia de la API de Blob Service, consulte API REST de Blob Service.
Servicio Cola
El servicio Cola proporciona un sistema de mensajería confiable y persistente, tanto dentro de los servicios como entre ellos. La API de REST para el servicio Cola expone dos recursos: colas y mensajes.
Las colas admiten metadatos definidos por el usuario en forma de pares nombre-valor especificados como encabezados en una operación de solicitud.
Cada cuenta de almacenamiento puede tener un número ilimitado de colas de mensajes con nombres exclusivos dentro de la cuenta. Cada cola de mensajes puede contener un número ilimitado de mensajes. El tamaño máximo de un mensaje se limita a 64 KiB para la versión 2011-08-18 y 8 KiB para versiones anteriores.
Cuando un mensaje se lee de la cola, se espera que el consumidor lo procese y lo elimine a continuación. Una vez leído el mensaje, este se vuelve invisible para los otros consumidores durante un intervalo especificado. Si el mensaje aún no se ha eliminado en el momento en que expira el intervalo, se restaura su visibilidad, de modo que otro consumidor pueda procesarlo.
Para obtener más información sobre Queue Service, consulte Queue Service REST API.
Servicio Tabla
Table service proporciona almacenamiento estructurado en forma de tabla. Table service admite una API REST que implementa el protocolo OData.
Dentro de una cuenta de almacenamiento, un desarrollador puede crear tablas. Las tablas almacenan datos en forma de entidades. Una entidad es una colección de propiedades con nombre y sus valores, similar a una fila. Las tablas tienen particiones para admitir el equilibrio de carga en los nodos de almacenamiento. Cada tabla tiene como primera propiedad una clave de partición que especifica la partición a la que pertenece una entidad. La segunda propiedad es una clave de fila que identifica una entidad en una partición determinada. La combinación de la clave de partición y la clave de fila forma una clave principal que identifica de forma única cada entidad en la tabla.
Table service no obliga a utilizar ningún esquema en particular. Los desarrolladores pueden elegir implementar y aplicar un esquema en el lado del cliente. Para obtener más información sobre Table service, consulte Table Service REST API.
Servicio de archivos
El protocolo bloque de mensajes del servidor (SMB) es el protocolo de recurso compartido de archivos preferido que se usa actualmente en el entorno local. El servicio Archivo de Microsoft Azure permite a los clientes aprovechar la disponibilidad y la escalabilidad del SMB de la infraestructura en la nube de Azure como servicio (IaaS) sin tener que reescribir aplicaciones cliente de SMB.
El servicio Archivo de Azure también ofrece una alternativa atractiva a las soluciones tradicionales de almacenamiento conectado directo (DAS) y red de área de almacenamiento (SAN), que con frecuencia son complejas y caras de instalar, configurar y poner en funcionamiento.
Los archivos almacenados en los recursos compartidos del servicio Archivo de Azure son accesibles mediante el protocolo SMB y las API de REST. El servicio File ofrece los cuatro recursos siguientes: la cuenta de almacenamiento, los recursos compartidos, los directorios y los archivos. Los recursos compartidos proporcionan una manera de organizar conjuntos de archivos y también se pueden montar como un recurso compartido de archivos mediante SMB hospedado en la nube.
Consulte también
API REST de La API REST de Blob ServiceRest APITable Service API REST API REST