Справочник по REST API службы хранилища Azure

Интерфейсы REST API для служб хранения Microsoft Azure предлагают программный доступ к службам BLOB-объектов, очередей, таблиц и файлов в Azure или в среде разработки через эмулятор хранения.

Все службы хранилища доступны через API-интерфейс REST. Доступ к службам хранилища можно получить из службы, выполняемой в Azure, или непосредственно через Интернет из любого приложения, способного отправлять запросы и получать ответы по протоколам HTTP/HTTPS.

Важно!

Службы хранилища Azure поддерживают и протокол HTTP, и протокол HTTPS, однако настоятельно рекомендуется использовать протокол HTTPS.

Учетная запись хранения

Весь доступ к службам хранения осуществляется через учетную запись хранения. Учетная запись хранения представляет собой пространство имен самого высокого уровня для доступа ко всем основным службам. Он также является основой для авторизации.

API-интерфейсы REST для служб хранилища предоставляют доступ к учетной записи хранилища как к ресурсу.

Служба BLOB-объектов

Служба BLOB-объектов обеспечивает хранение таких сущностей, как двоичные и текстовые файлы. REST API для службы BLOB-объектов предоставляет два ресурса: контейнеры и большие двоичные объекты. Контейнер похож на папку, содержащую набор больших двоичных объектов; каждый большой двоичный объект должен находиться в контейнере. Служба BLOB-объектов определяет три типа BLOB-объектов:

  • Блочные BLOB-объекты, оптимизированные для потоков. Этот тип больших двоичных объектов — единственный доступный в версиях, выпущенных до 2009-09-19.

  • Страничные BLOB-объекты, оптимизированные для случайных операций чтения и записи, предоставляющие возможность записи диапазона байтов в BLOB-объект. Страничные большие двоичные объекты доступны только начиная с версии 2009-09-19. Они в основном используются для файлов VHD, которые хранятся в виртуальных машинах AzureVM.

  • Добавочные BLOB-объекты, оптимизированные только для операций добавления. Добавочные BLOB-объекты доступны только в версии 2015-02-21 и более поздних.

Контейнеры и большие двоичные объекты поддерживают определяемые пользователем метаданные в форме пар «имя-значение», заданных как заголовки в операции запроса.

С помощью API-интерфейса REST для службы BLOB-объектов разработчики могут создавать иерархические пространства имен, подобные файловым системам. В именах больших двоичных объектов посредством настраиваемого разделителя пути может кодироваться иерархия. Например, имена BLOB-объектов MyGroup/MyBlob1 и MyGroup/MyBlob2 подразумевают виртуальный уровень организации больших двоичных объектов. Операция перечисления для больших двоичных объектов поддерживает проход по виртуальной иерархии аналогично файловой системе, при этом она позволяет возвращать набор больших двоичных объектов, упорядоченных в составе группы. Например, можно перечислить все большие двоичные объекты, упорядоченные в myGroup/.

Большой двоичный объект блочного типа можно создать двумя способами. Вы можете отправить большой двоичный объект с помощью одной операции Put BLOB-объект или отправить большой двоичный объект в виде набора блоков с помощью операции Put Block и зафиксировать блоки в большой двоичный объект с помощью операции Put Block List .

Страничные BLOB-объекты создаются и инициализируются с максимальным размером с помощью вызова Put BLOB-объекта. Чтобы записать содержимое в страничный BLOB-объект, вызовите операцию Вставка страницы .

Добавочные BLOB-объекты можно создать путем вызова Put BLOB-объектов. Добавочный BLOB-объект, созданный с помощью операции "Поместить BLOB-объект ", не содержит никакого содержимого. Чтобы записать содержимое в добавочный BLOB-объект, добавьте блоки в конец большого двоичного объекта, вызвав операцию Добавления блока . Обновление или удаление существующих блоков не поддерживается. Каждый блок может иметь разный размер, не более 4 МиБ. Максимальный размер добавочного BLOB-объекта составляет 195 ГиБ, а добавочный BLOB-объект может включать не более 50 000 блоков.

Большие двоичные объекты поддерживают операции условного обновления, которые могут быть полезны для управления параллелизмом и эффективной отправки.

Большие двоичные объекты можно считывать, вызвав операцию Получения BLOB-объекта . Клиент может прочесть весь большой двоичный объект или произвольный диапазон байтов.

Справочник по API службы BLOB-объектов см. в разделе REST API службы BLOB-объектов.

Служба очередей

Служба очередей обеспечивает надежный механизм обмена сообщениями в службах и между ними с сохранением данных. REST API для службы очередей предоставляет два ресурса: очереди и сообщения.

Очереди поддерживают определяемые пользователем метаданные в форме пар «имя-значение», заданных как заголовки в операции запроса.

Каждая учетная запись хранилища может содержать неограниченное число очередей сообщений, имена которых должны быть уникальными в рамках учетной записи. Каждая очередь сообщений может содержать неограниченное число сообщений. Максимальный размер сообщения ограничен 64 КиБ для версии 2011-08-18 и 8 КиБ для предыдущих версий.

При чтении сообщения из очереди предполагается, что потребитель обработает сообщение и удалит его. После прочтения сообщения оно становится невидимым для других потребителей на указанный промежуток времени. Если сообщение еще не было удалено на момент окончания этого промежутка, оно снова становится видимым и может обрабатываться другим потребителем.

Дополнительные сведения о службе очередей см. в разделе REST API службы очередей.

Служба таблиц

Служба таблиц предоставляет структурированное хранилище в виде таблиц. Служба таблиц поддерживает REST API, реализующий протокол OData.

В учетной записи хранения разработчик может создавать таблицы. В таблицах данные хранятся в форме сущностей. Сущность — это коллекция именованных свойств и их значений, подобная строке. Таблицы разбиваются для поддержки балансировки нагрузки между узлами хранилища. Первым свойством каждой таблицы является ключ секции, указывающий, к какой секции принадлежит сущность. Вторым свойством является ключ строки, идентифицирующий сущность в указанной секции. Сочетание ключа секции и ключа строки составляет первичный ключ, однозначно идентифицирующий каждую из сущностей в таблице.

Служба таблиц не применяет принудительно какую-либо схему. Разработчик может решить реализовать и принудительно применить схему на стороне клиента. Дополнительные сведения о службе таблиц см. в разделе REST API службы таблиц.

Служба файлов

Протокол SMB является предпочтительным протоколом общей папки, используемым в локальной среде. Файловая служба Microsoft Azure позволяет клиентам использовать доступность и масштабируемость SMB облачной инфраструктуры Azure как службы (IaaS) без переписывания клиентских приложений SMB.

Файловая служба Azure также предлагает привлекательную альтернативу традиционным решениям непосредственно присоединенного хранилища (DAS) и сети хранения данных (SAN), которые часто оказываются слишком сложными и затратными в установке, настройке и работе.

Файлы, хранящиеся в общих папках службы файлов Azure, доступны по протоколу SMB, а также через интерфейсы API REST. Служба файлов предлагает следующие четыре ресурса: учетную запись хранения, общие папки, каталоги и файлы. Общие папки позволяют упорядочить наборы файлов. Их можно подключить как общий файловый ресурс SMB, размещенный в облаке.

См. также раздел

REST API службы blob-объектов СЛУЖБЫ очередей REST APIслужбы таблиц REST APIслужбы файлов REST API