Продажи: 1-800-867-1389

Справочник по API-интерфейсу REST служб хранилища

Обновлено: Декабрь 2014 г.

API-интерфейсы REST для служб хранения Windows® Azure™ предлагают разработчикам программный способ доступа к службам больших двоичных объектов, очередей, таблиц и файлов в Azure или в среде разработки с помощью эмулятора хранилища.

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

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

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

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

Описание создания учетной записи хранилища и управления ей см. в разделе Управление учетными записями, подписками и административными ролями.

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

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

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

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

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

Большой двоичный объект блочного типа можно создать двумя способами. Большие двоичные объекты блочного типа размером до 64 МБ включительно можно передавать, вызвав операцию Вставка большого двоичного объекта. Большие двоичные объекты блочного типа размером более 64 МБ необходимо передавать в виде набора блокировок, каждая из которых должна быть не больше 4 МБ. Набор успешно переданных блокировок можно собрать в указанном порядке в один непрерывный большой двоичных объект, вызвав Вставка списка блокировок. В настоящее время максимальный поддерживаемый размер большого двоичного объекта блочного типа составляет 200 ГБ.

Большие двоичные объекты страничного типа создаются и инициализируются с максимальным размером путем вызова Вставка большого двоичного объекта. Для записи содержимого в большой двоичный объект страничного типа вызывается операция Вставка страницы. В настоящее время максимальный поддерживаемый размер большого двоичного объекта страничного типа составляет 1 ТБ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2014 Microsoft