ГОСТ Р ИСО/МЭК 17826-2015 Информационные технологии (ИТ). Интерфейс управления облачными данными (CDMI).

ГОСТ Р ИСО/МЭК 17826-2015

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационные технологии

 ИНТЕРФЕЙС УПРАВЛЕНИЯ ОБЛАЧНЫМИ ДАННЫМИ (CDMI)

Information technology. Cloud Data Management Interface (CDMI)

ОКС 35.040

Дата введения 2016-06-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО "ИАВЦ") на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 мая 2015 г. N 467-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 17826:2012* "Информационные технологии. Интерфейс управления облачными данными (CDMI)" (ISO/IEC 17826:2012 "Information technology - Cloud Data Management Interface (CDMI)").

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

 Введение

Настоящий стандарт CDMI

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

Настоящий стандарт состоит из следующих разделов:

      1 Область применения

Настоящий стандарт CDMI

описывает интерфейс доступа к облачному хранилищу и управления хранимой там информацией. Настоящий стандарт предназначен для разработчиков, использующих или внедряющих облачное хранение данных.

      2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты*. Предоставленные спецификации, не относящиеся к документам ИСО/МЭК, МЭК, ИСО и ITU, применимы лишь в контексте настоящего стандарта. Ссылка на эти документы не предоставляет им нового статуса в системе ИСО/МЭК. В частности, это не дает цитированным ссылкам статуса международного стандарта.

ИСО 3166 Коды для представления названий стран и единиц их административно-территориального деления (части 1, 2 и 3) (ISO 3166, Codes for the representation of names of countries and their subdivisions)

ИСО 4217:2008 Коды для представления валют и фондов (ISO 4217:2008, Codes for the representation of currencies and funds)

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats - Information interchange - Representation of dates and times)

ИСО/МЭК 9594-8:2008 Информационные технологии. Взаимосвязь открытых систем. Директория. Часть 8. Структура сертификата на открытый ключ и атрибуты (ISO/IEC 9594-8:2008, Information technology - Open Systems Interconnection - The Directory: Publickey and attribute certificate frameworks)

ИСО/МЭК 14776-414 Информационные технологии. Интерфейс для малых вычислительных систем (SCSI). Часть 414. Структурная модель 4 (SAM-4) (ISO/IEC 14776-414, SCSI Architecture Model - 4 (SAM-4))

IEEE Std 1003.1, 2004, POSIX ERE Открытая группа, основные спецификации, Вып.6 (IEEE Std 1003.1, 2004, POSIX ERE, The Open Group, Base Specifications Issue 6) - http://www.unix.org/version3/ieee_std.html

RFC 2045 Многоцелевые расширения почты для интернета (MIME) Часть 1. Формат тела письма в интернете (RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies) - http://www.ietf.org/rfc/rfc2045.txt

RFC 2119 Ключевые слова для обозначения уровня требований в RFC (RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels) - http://tools.ietf.org/html/rfc2119

RFC 2246 Протокол TLS версии 1.0 (RFC 2246, The TLS Protocol Version 1.0) - http://www.ietf.org/rfc/rfc2246.txt

RFC 2578 Структура управляющей информации, версия 2 (RFC 2578, Structure of Management Information Version 2, SMIv2) - http://www.ietf.org/rfc/rfc2578.txt

RFC 2616 Протокол передачи гипертекста 1.1 (RFC 2616, Hypertext Transfer Protocol - HTTP/1.1) - http://www.ietf.оrg/rfc/rfc2616.txt

RFC 2617 Аутентификация HTTP: Базовая аутентификация доступа и аутентификация доступа с использованием дайджеста (RFC 2617, HTTP Authentication: Basic and Digest Access Authentication) - http://www.ietf.оrg/rfc/rfc2617.txt

RFC 3280 Профиль инфраструктуры открытых ключей Х.509 Интернета: сертификат и список отозванных сертификатов (RFC 3280, Internet Х.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) - http://www.ietf.org/rfc/rfc3280.txt

RFC 3530 Протокол сетевой файловой системы версии 4 (RFC 3530, Network File System (NFS) Version 4 Protocol) - http://www.ietf.org/rfc/rfc3530.txt

RFC 3720 Интерфейс для малых вычислительных систем в интернете (RFC 3720, Internet Small Computer Systems Interface, iSCSI) - http://www.ietf.org/rfc/rfc3720.txt

RFC 3986 Универсальный идентификатор ресурса: общий синтаксис (RFC 3986, Uniform Resource Identifier (URI): Generic Syntax) - http://www.ietf.org/rfc/rfc3986.txt

RFC 4346 Протокол безопасности транспортного уровня, версия 1.1 (RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1) - http://www.ietf.org/rfc/rfc4346.txt

RFC 4627 Тип медиа application/JSON для объектной нотации JavaScript (RFC 4627, The Application/JSON Media Type for JavaScript Object Notation (JSON)) - http://www.ietf.org/rfc/rfc4627.txt

RFC 4648 Кодировки данных Base16, Base32, и Base64 (RFC 4648, The Base16, Base32, and Base64 Data Encodings) http://www.ietf.org/rfc/rfc4648.txt

RFC 4918 Расширения HTTP для авторства и версионирования в сети Интернет (RFC 4918, HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)) - http://www.ietf.org/rfc/rfc4918.txt

RFC 5246 Протокол безопасности транспортного уровня, версия 1.2 (RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2) - http://www.ietf.org/rfc/rfc5246.txt

RFC 6208 Типы медиа для интерфейса управления облачными данными (RFC 6208, Cloud Data Management Interface (CDMI) Media Types) - http://www.ietf.org/rfc/rfc6208.txt

      3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 список управления доступом (Access Control List) ACL: Постоянный список, состоящий из записей управления доступом (Access Control Entries, АСЕ), который перечисляет права доступа принципалов (пользователей и групп) к ресурсам.

3.2

CDMI

: Интерфейс управления облачными данными.

3.3 CIFS: Единая файловая система для Интернета.

3.4 облачное хранение (cloud storage): См. "Хранение данных как служба".

3.5 CRC: Циклический избыточный код.

3.6 CRUD: Создать, получить, изменить, удалить (create, retrieve, update, delete).

3.7 хранение данных как служба (data storage as a Service) DaaS: Организация сетевых служб виртуализированного хранения и доступа к данным, основанная на требовании заданного уровня службы, что снимает границы масштабируемости; является самообеспечивающимся или не требующем обеспечения и оплачивается в зависимости потребления.

3.8 домен (domain): Совместная база данных прав пользователей, содержащая пользователей, группы, их политики безопасности и связанную информацию об учетных записях.

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

3.9 целостность в конечном итоге (eventual consistency): Поведение транзактной системы, не предоставляющее гарантию связности в каждый момент времени, что улучшает доступность системы и ее устойчивость к распадению сети.

3.10 HTTP: Протокол передачи гипертекста.

3.11 инфраструктура как служба (Infrastructure as a Service) laaS: Предоставление по сети соответствующим образом сконфигурированного виртуального вычислительного окружения, основанное на запрошенном уровне услуг.

Примечание - Обычно laaS является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости потребления.*

3.12 iSCSI: Интерфейс для малых вычислительных систем в интернете (см. RFC 3720).

3.13 LUN: Номер логического устройства (см. ИСО/МЭК 14776-414).

3.14 MIME: Многоцелевые расширения для почты в интернете (см. RFC 2045)

3.15 NFS: Сетевая файловая система (см. RFC 3530).

3.16 объект (object): Сущность, имеющая идентификатор объекта (ID), уникальный URI, и обладающая состоянием.

Примечание - Существуют следующие типы объектов CDMI: объекты данных, контейнеры, опции, домены, очереди.

3.17 идентификатор объекта (object identifier): Глобально-уникальное значение, соотнесенное с объектом в момент его создания.

3.18 OCCI: Интерфейс открытых облачных вычислений (Open Cloud Computing Interface) (см. спецификацию OCCI).

3.19 платформа как служба PaaS (Platform as a Service): Предоставление по сети виртуализированной среды программирования, состоящей из развернутого стека приложения, основанного на виртуальной вычислительной среде.

Примечание - Обычно PaaS основана на laaS, является самообеспечивающейся или не требующей обеспечения и оплачивается в зависимости фактического использования.*

3.20 POSIX: Интерфейс переносимой операционной системы (Portable Operating System Interface) (см. IEEE Std 1003.1).

3.21 частное облако (private cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS ограниченному числу пользователей, обычно принадлежащих к одной и той же организации.

Примечание - Частные облака создаются в целях безопасности.

3.22 общественное облако (public cloud): Предоставление SaaS, PaaS, laaS, и/или DaaS потенциально неограниченному количеству пользователей.

3.23 передача репрезентативного состояния (Representational State Transfer) REST: Особый набор принципов определения, адресации и взаимодействия с ресурсами, адресуемыми посредством URI (см. [REST]).

3.24 RPO: Целевая точка восстановления (recovery point objective).

3.25 RTO: Целевое время восстановления (recovery time objective).

3.26 уровень службы (service level): Целевые показатели производительности службы.

3.27 программы как служба (Software as a Service) SaaS: Предоставление по сети доступа к приложению по запросу.

3.28 тонкое резервирование (thin provisioning): Технология распределения физической емкости тома или файловой системы по мере записи данных приложением вместо предварительного резервирования.

3.29 универсальный идентификатор ресурса (Uniform Resource Identifier) URI: Короткая последовательность символов, идентифицирующая абстрактный или физический ресурс (см. RFC 3986).

3.30 виртуализация (virtualization): Представление ресурсов, как если бы они были физическими, тогда как на самом деле они отделены от базовых физических ресурсов.

3.31 WebDAV: Набор расширений и дополнений к протоколу HTTP, поддерживающих совместную работу пользователей над редактированием файлов и управление файлами на удаленных веб-серверах (см. RFC 4918).

3.32 ХАМ: Расширяемый метод доступа (eХtensible Access Method) (см. INCITS 464-2010).

      4 Соглашения

      4.1 Формат интерфейса

Каждое описание интерфейса состоит из девяти компонентов, описанных в таблице 1.

Таблица 1 - Формат интерфейса

      4.2 Типографские соглашения

Все исходные тексты программ и сообщений показаны следующим шрифтом:

Пример -

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain",

"metadata" : {

},

"value" : "This is the Value of this Data Object"

}

      4.3 Требования к телу сообщений запросов и ответов

В таблицах, представляющих тела запросов и ответов, колонка "Требования" содержит одно из трех значений:

- обязательное. Значение, описанное в данной строке, должно быть указано.

- условное. Если выполнены условия, указанные в ячейке "Описание" данной строки (слева от ячейки "Требования") то значение, описанное в данной строке, должно быть указано. В противном случае, оно может быть указано, если это не запрещено в Описании (в этом случае оно должно отсутствовать);

- необязательное. Значение, описанное в данной строке, может быть указано.

      4.4 Требования к ключевым словам

В данном международном стандарте, ключевые слова, указанные в табл.2, должны интерпретироваться как указано в RFC 2119.

Таблица 2 - Требования к ключевым словам

      5 Обзор облачного хранения

      5.1 Введение

При обсуждении облачного хранения и стандартов важно различать ресурсы, предлагаемые как службы. Эти ресурсы открыты пользователям как функциональные интерфейсы (например, пути к данным) и управляются интерфейсами управления (например, пути управления). Настоящий стандарт представляет различные типы интерфейсов, которые входят в состав существующих реализаций, и указывает, как они взаимосвязаны. Настоящий стандарт определяет модель интерфейсов, которая может быть отражена на различные реализации, и модель, которая послужит основой для интерфейсов облачного хранения в будущем.

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

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

      5.2 Что такое облачное хранение?

Использование термина "облако" связано с тем, что эти новые модели произошли от графического представления архитектур, использующих облако как символ сети. Облако абстрактно обозначает связь любого компьютера сети с любым другим компьютером. В этой абстракции сетевое соединение в облаке не определяет, как именно оно устанавливается.

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

Таким образом, облачное хранение есть предоставление по запросу виртуализированного хранилища. Для обозначения этого используется формальный термин "Хранение данных как служба" (Data storage as a Service, DaaS).

      5.3 Хранение данных как служба

Абстрагирование хранения данных от набора интерфейсов служб и предоставление его по запросу допускает большое количество конкретных реализаций и сценариев работы. Единственный тип хранения, который исключается из данного определения - тот, который предоставляется на основе фиксированных приращений, а не основанный на запросах.

Важная часть реализации любой системы DaaS - поддержка унаследованных клиентов. Эта поддержка включена в действующие стандартные протоколы, такие как iSCSI (и другие) для блочного и CIFS/NFS или WebDAV для файлового и сетевого хранения, как показано на рисунке 1.     

Рисунок 1 - Существующие стандарты интерфейсов хранилищ данных

Различие между приобретением обычного устройства и облачного хранилища состоит не в функциональных интерфейсах, а в том, что в последнем случае хранилище предоставляется по запросу. Пользователь платит либо за то, чем фактически пользуется, либо за то, что запросил для использования. В случае блочного хранилища размер запрошенного объема измеряется в виртуальных томах или номерах логического устройства (LUN). В случае файловых протоколов, единицей измерения является файл. В любом случае, действительный объем хранилища может быть тонко зарезервирован и оплачен исходя из действительного использования. Для дальнейшего снижения фактически используемого объема могут использоваться такие службы данных, такие как сжатие или удаление дубликатов.*

Управление таким хранилищем в случае стандартных интерфейсов хранения данных обычно осуществляется через API или (чаще) через пользовательский интерфейс администратора в браузере по выделенному каналу связи. Этот интерфейс по выделенному каналу связи может использоваться для запуска других служб данных (например, создания моментального снимка состояния или клонирования).

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

Каждый объект данных создается, получается, обновляется и уничтожается как отдельный ресурс. В этом интерфейсе контейнер, если он используется, служит для удобства, группируя объекты данных. Ничто не препятствует создавать иерархические контейнеры, хотя каждая конкретная реализация может поддерживать лишь единственный уровень (см. рисунок 2).     

Рисунок 2 - Интерфейсы хранилища для данных клиента объектного хранилища

      5.4 Управление данными для облачного хранения

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

Облачное хранение может потерять свои преимущества абстрактности и простоты, если появятся новые службы данных, требующие сложного управления. Клиенты облачных хранилищ, вероятно, будут не согласны тратить время на дополнительные операции (например, настраивать через специализированные интерфейсы резервное копирование по расписанию, разворачивать службу данных индивидуально для каждого элемента данных).

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

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

Метаданные системы хранения формируются/интерпретируются реализацией облака и низкоуровневыми функциями хранилища (например, статистика изменения и доступа, управление доступом). Подробнее о поддержке метаданных системы хранения см. 16.3.

Метаданные системы данных интерпретируются реализацией облака как требования к данным, которые управляют операциями соответствующих служб данных. Это может относиться к объединению данных в контейнере или к индивидуальным объектам данных, если реализация поддерживает такую детализацию. Подробнее о поддержке метаданных системы данных см. 16.4.

      5.5 Управление данными и контейнерами

Нет причины, по которой управление данными и контейнерами должно осуществляться различными интерфейсами.

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

Даже если предоставляемый интерфейс не поддерживает установку метаданных для индивидуальных элементов, метаданные могут быть настроены для контейнеров. В этом случае, интерфейс не предоставляет механизма для перекрывания метаданных, которые индивидуальный элемент наследует от родительского контейнера. Для интерфейсов, основанных на файлах, поддерживающих расширенные атрибуты (например, CIFS, NFSv4), эти атрибуты могут быть использованы для указания на то, что метаданные системы данных должны перекрыть метаданные контейнера.

      5.6 Эталонная модель интерфейсов облачного хранения

Эталонная модель облачного хранилища показана на рисунке 3.     

Рисунок 3 - Эталонная модель облачного хранилища

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

Службы данных применяются к индивидуальным элементам данных в соответствии с метаданными системы данных. Метаданные определяют требования к данным на основании индивидуальных элементов или групп элементов (контейнеров).

      5.7 Интерфейс управления облачными данными

Интерфейс управления облачными данными (CDMI

), показанный на рисунке 3, может использоваться для создания, доступа, изменения или удаления объектов в облаке. Функции CDMI позволяют:

- клиентам определить набор опций, поддерживаемых реализацией облака;

- управлять контейнерами и данными в них;

- устанавливать метаданные для контейнеров и объектов данных в них.

Настоящий стандарт разделяет стандартные операции на два типа: использующие тип содержимого CDMI в теле HTTP и не использующие их. Несмотря на то, что многие данные доступны посредством операций обоих типов, предоставление и тех, и других операций позволяет взаимодействовать с провайдером CDMI как клиентам, поддерживающим CDMI, так и не поддерживающим CDMI.

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

Совместимые облачные реализации могут поддерживать подмножество CDMI, если они предоставляют через интерфейс сведения об ограничениях опций.

Настоящий стандарт использует принципы REST в разработке интерфейса, насколько это возможно (см. [REST]).

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

Не требуется, чтобы только CDMI использовался для путей к данным. CDMI может управлять свойствами облачного хранилища для произвольного интерфейса пути к данным (например, стандартизованного или проприетарного некоторого поставщика).

Метаданные контейнера используются для конфигурирования требований к данным хранилища, предъявляемых контейнером посредством экспортируемых протоколы (например, блочный или файловый протокол). Для реализаций, основанных на файловой системе для блочного хранения данных (например, iSCSI), контейнер CDMI предоставляет полезную абстракцию для представления метаданных системы данных для данных и структур, управляющих экспортированными протоколами.

Реализация облака может также поддерживать домены, позволяющие сопоставлять административные права владения хранимым объектам. Домены (наряду с другими возможностями) позволяют стандарту:

- определять соответствие пользовательских полномочий принципалами из списков контроля доступа (ACL);

- выдавать специальные привилегии, связанные с облаком;

- делегировать авторизацию пользователей внешней системе авторизации пользователей (например, LDAP или Active Directory).

Домены также могут быть иерархическими, позволяя создавать корпоративные домены с многочисленными дочерними доменами для отделов или индивидуальных пользователей. Концепция домена может использоваться для агрегирования данных пользователей для оплаты или мониторинга использования облака.

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

Например, в 5.10, настоящий стандарт указывает, что "каждая облачная система хранения должна обеспечивать доступ к хранимым объектам по ID". Данное требование должно пониматься в контексте, что у функции доступа к ID объекта есть предусловие - наличие опции cdmi_object_access_by_ID.

      5.8 Объектная модель для CDMI

Модель для CDMI показана на рисунке 4     

Рисунок 4 - Модель объекта CDMI

В таблице 3 перечислены пять типов ресурсов. Содержание каждой конкретной операции зависит от типа ресурса.

Таблица 3 - Типы ресурсов в модели

Для операций хранения данных клиенту интерфейса достаточно информации о контейнерах и объектах данных. Реализации путей к данным должны поддерживать хотя бы один уровень контейнеров (см. 5.5). С использованием объектной модели CDMI (см. рисунок 4) клиент может отослать запрос PUT через CDMI (см. 5.6) с URI нового контейнера и создать новый контейнер с определенным именем. Метаданные контейнера опциональны и выражаются набором пар имя-значение. После создания контейнера клиент может отправить запрос PUT для создания объекта данных внутри нового контейнера. Последующий запрос GET выбирает объект данных, включая поле значения.

Определены также объекты очереди (см. рисунок 4) со специальными свойствами для упорядоченного, в дисциплине FIFO, создания и удаления значений. Подробнее см. в разделе 11.

CDMI определяет два пространства имен, которые могут использоваться для доступа к хранимым объектам: плоское пространство идентификаторов объектов и иерархическое пространство имен-путей. Поддержка доступа к объекту по ID выражается глобальной опцией cdmi_object_access_by_ID, а поддержка иерархических путей определяется опцией контейнера cdmi_create_dataobject, находящейся в корневом или вложенном контейнере.

Объекты создаются по ID выполнением команды HTTP POST с определенным URI, обозначаемым как /cdmi_objectid/ (см. 9.8). После создания клиенты могут объект командой PUT с указанием ID объекта, присвоенный сервером CDMI, используя /cdmi_objectid/ URI (см. 8.6)*. Этот URI используется также для извлечения и удаления объектов по ID.

Объекты создаются по имени выполнением HTTP PUT с указанием URI пути (см. 8.2). После создания, объекты можно модифицировать, выполняя команды PUT с указанием пути к объекту, заданному клиентом (см. 8.6). То же самый URI используется для извлечения и удаления объектов*.

CDMI определяет механизмы, позволяющие сопоставить путь в иерархическом пространстве объекту, имеющему лишь ID, а также позволяющие удалить путь, оставив только ID, у объекта, имеющего и путь, и ID. Это осуществляется с использованием модификатора перемещения для операций PUT или POST, как показано на рисунок 5.     

Рисунок 5 - Диаграмма переходов объекта: добавление имени и удаление имени

      5.9 Метаданные CDMI

CDMI использует много видов метаданных, включая метаданные HTTP, метаданные системы данных, пользовательские метаданные и метаданные системы хранения.

Метаданные HTTP - это метаданные, связанные с использованием протокола HTTP (например, Content-Length, Content-Type и др.). Метаданные HTTP не связаны с данным международным стандартом, но их необходимо обсудить для объяснения, как CDMI использует стандарт HTTP.

Метаданные системы данных CDMI, пользовательские метаданные и метаданные системы хранения определятся в форме пар имя-значение. Метаданные системы данных, определенные производителем, должны начинаться с обращенного доменного имени производителя.

Метаданные системы данных - это метаданные, определяемые клиентом CDMI, они входят в состав объекта. Метаданные системы данных абстрактно определяют требования к данным, связанные со службами данных, предоставляемыми облачным хранилищем.

Пользовательские метаданные состоят из определенных клиентом строк, массивов и объектов в нотации JSON, сохраненных в поле метаданных. Пространство имен для пользовательских метаданных является самоуправляемым (например, использует обращенное имя домена), причем имена пользовательских метаданных не должны начинаться с префикса "cdmi_".

Метаданные системы хранения - это метаданные, сгенерированные службами хранения системы (например, время создания или размер) для предоставления необходимой информации клиенту CDMI.

Матрица создания и использования метаданных системы хранения приведена в табл.4.

Таблица 4 - Создание-использование метаданных системы хранения

      5.10 ID объекта

Каждому объекту, хранимому в CDMI-совместимой системе, в момент создания ставится в соответствие глобально-уникальный идентификатор объекта (ID). ID объекта CDMI - это строка, на которую накладываются требования, обеспечивающие ее правильное создание и уникальность. Каждая реализация CDMI способна создавать уникальные идентификаторы, не конфликтуя с другими реализациями.

Каждая облачная система хранения должна предоставлять доступ к хранимым объектам по ID посредством добавления ID объекта к URI корневого контейнера. Если объект данных "MyDataObject.txt" имеет ID "00006FFD001001CCE3B2B4F602032653", следующая пара URI дает доступ к одному и тому же объекту данных:

http://cloud.example.com/root/MyDataObject.txt

http://cloud.example.com/root/cdmi_objectid/00006FFD001001CCE3B2B4F602032653

Если поддерживается работа с контейнерами, они также должны быть доступными по ID объекта. Если контейнер "MyContainer" имеет ID объекта "00006FFD0010AA33D8CEF9711E0835CA", следующие пары URI дают доступ к одному и тому же объекту данных:

http://cloud.example.com/MyContainer/

http://cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/

http://cloud.example.com/MyContainer/MyDataObject.txt

http://cloud.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA/MyDataObject.txt

      5.11 Формат идентификатора объекта CDMI

Каждая реализация должна создавать ID объекта, однозначно идентифицирующий объект. ID объекта должен быть глобально-уникальным и должен отвечать формату, определенному на рисунке 6. Исходный формат ID объекта - строка байт переменной длины (максимум 40 байт). Приложение обращается с объектом ID как с непрозрачной байтовой строкой. Тем не менее, формат ID объекта определен так, что его целостность может быть проверена и независимые реализации могут независимо создавать уникальные ID Объектов.     

Рисунок 6 - Формат ID объекта

Поля, показанные на рисунке 6, определены следующим образом:

- Зарезервированные байты должны быть нулевыми.

Поле номера организации - это код, присвоенный организации, чья реализация создает ID объекта, в спецификации SNMP, в сетевом порядке байтов. См. RFC 2578 и http://www.iana.org/assignments/enterprise-numbers. Код 0 зарезервирован.

Байт со смещением 5 должен содержать длину ID в байтах.

Поле CRC должно содержать двухбайтовый (16-битный) CRC в сетевом порядке байтов. Это поле позволяет контролировать целостность ID объекта. Поле CRC должно заполняться выполнением алгоритма (см. [CRC]) по всем байтам ID объекта, определенным полем Длина, при обнуленном поле CRC. Вычисление CRC определяется набором параметров:

- Name : "CRC-16",

- Width : 16,

- Poly : 0x8005,

- Init : 0x0000,

- Refln : True,

- RefOut : True,

- XorOut : 0x0000, и

- Check : 0xBB3D.

Эта функция возвращает 16-битный CRC по полиному 0x8005, обращенным входом и обращенным результатом. Алгоритм вычисления CRC-16 определен в [CRC].

- Непрозрачные данные ID каждого объекта должны быть уникальными в пределах одного номера организации.

Исходный формат объекта ID - бинарный. При необходимости, например при включении в URI или строки JSON, текстовое представление ID объекта должно кодироваться на основе правил base 16, описанных в [RFC 4648] и не должно учитывать регистр.

      5.12 Безопасность

В контексте CDMI безопасность относится к защитным мерам, применяемым при управлении и доступе к данным и хранилищу. В частности, система безопасности должна решать следующие задачи:

- предоставление механизма, обеспечивающего невозможность прочтения третьей стороной обмен данными между CDMI клиентом и сервером;

- предоставление механизма, позволяющего CDMI клиентам и серверам доказывать свою идентичность;

- предоставление механизма, позволяющего управлять разрешенными действиями CDMI клиента на CDMI сервере;

- предоставление механизма для записи действий, выполненных CDMI клиентом на CDMI сервере;

- предоставление механизмов защиты данных в фоновом режиме;

- предоставление механизмов контролируемого удаления данных;

- предоставление механизма для определения набора опций безопасности конкретной реализации.

Меры безопасности, включенные в CDMI, можно описать как:

- безопасная передача;

- аутентификация пользователей и сущностей;

- авторизация и контроль доступа;

- целостность данных;

- очистка данных и среды;

- удерживание данных;

- защита от вредоносных действий;

- шифрование данных в фоновом режиме;

- опции безопасности.

За исключением безопасности передачи и опций безопасности, которые обязательны для реализации, остальные меры безопасности существенно зависят от конкретной реализации.

Если безопасность является важной задачей, CDMI клиент должен начинать работу с серии поисков опций безопасности (см. подпункт 12.1.1) для определения точной природы возможных мер безопасности. Основываясь на значениях опций и оценке рисков, принимается решение о том, может ли использоваться данный сервер CDMI. Это особенно важно, если в облаке будут храниться ценные данные или данные ограниченного доступа, и требуется определенная защита (шифрование) или особая обработка данных (например, опция записи и просмотра всех выполняемых действий).

HTTP является обязательным механизмом передачи данных, a HTTP над TLS (то есть, HTTPS) является механизмом, используемым для безопасного взаимодействия между клиентами и сервером CDMI. Для обеспечения безопасности и совместимости, все реализации CDMI должны поддерживать протокол безопасности транспортного уровня (Transport Layer Security, TLS) как описано в приложении А, но его использование клиентами и сервером CDMI опционально.

      5.13 Необходимая поддержка HTTP

5.13.1 Требования поддержки RFC 2616

Совместимая реализация CDMI должна также включать реализацию RFC2616 (см. [RFC 2616]) (т.е., HTTP 1.1). Перечисленные ниже примеры описывают некоторые части RFC 2616, которые должны поддерживаться, но этот список не является исчерпывающим.

5.13.2 Согласование типа содержимого

Для операций CDMI используются типы медиа CDMI объектов, определенные в [RFC 6208].

Клиент может опционально предоставлять заголовок HTTP Accept согласно 14.1 RFC 2616. Если клиент требует, чтобы в ответе содержался определенный тип медиа CDMI, соответствующий тип должен быть указан в заголовке Accept. Иначе, заголовок может содержать "*/*" или список типов, или быть опущен.

Если в сообщении-запросе присутствует тело, клиент должен включать заголовок Content-Type согласно пункту 14.17 RFC 2616. Если в таком случае клиент не предоставляет заголовок Content-Type содержимого или тип медиа в заголовке Content-Type не соответствует существующему типу ресурса, сервер должен вернуть код состояния HTTP 400 Bad Request.

Если в сообщении-ответе присутствует тело, сервер должен предоставить заголовок Content-Type.

Настоящий стандарт допускает дальнейшие согласования типа содержимого (например, в 9.3 отсутствие заголовка Content-Type несет особую информацию).

5.13.3 Поддержка диапазона

Сервер должен поддерживать заголовки HTTP Range и ответы с частичным содержимым (см. 14.16 RFC 2616).

5.13.4 Экранирование в URI

Ко всем строкам, использованным в URI, должно применяться экранирование зарезервированных символов знаком процента (%), определенное в RFC 3986. Это касается имен полей, предоставленных пользователем, имен метаданных, имен объектов, имен контейнеров и имен доменов, использованных в URI.

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

Пример - Клиент, получающий метаданные объекта "@user" из контейнера "@MyContainer", должен выполнить следующий запрос:

GET /%40MyContainer/?objectName;metadata:%40user HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

В ответ должно быть получено:

НТТР/1.1 200 ОK

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"objectName": "@MyContainer>,

"metadata": {

"@user": "test"

}

}

5.13.5 Использование URI

Формат и синтаксис URI определяются RFC 3986.

Каждый клиент CDMI должен поддерживать один или несколько корневых URI, чтобы каждый из них соответствовал корневому контейнеру сервера CDMI. Так как все URI контейнеров CDMI завершаются наклонной чертой, все корневые URI также завершаются наклонной чертой.

Все URI в данном международном* являются относительными (relative) URI, заданными относительно корневых URI, если не сказано иное. Таким образом, в качестве алгоритма разрешения URI используется алгоритм из пункта 5.2 RFC 3986.

В таблице 5 приведено разрешение относительного URI по корневому URI.

Таблица 5 - Разрешение относительного URI по корневому URI

Настоящий стандарт не накладывает ограничений на корневые и относительные URI. Все примеры, приведенные в таблице 5, допустимы, используя корневой URI http://cloud.example.com/ и возвращая ссылки на абсолютные пути, как показано во второй строке таблицу 5.

5.13.6 Зарезервированные символы

Имена объектов данных CDMI, контейнеров, очередей, доменов и объектов опций не могут содержать символы "/" и "?", так как они зарезервированы как разделители.

      5.14 Представление времени

Если не указано иное, все значения даты/времени даются согласно расширенному представлению ИСО 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ). Должна быть указана полная точность, разделитель долей секунды "." (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

Если не указано иное, все интервалы даты/времени должны быть в формате начальная дата/конечная дата в соответствии со стандартом ISO 8601:2004 (YYYY-MM-DDThh:mm:ss.ssssssZ/YYYY-MM-DDThh:mm:ss.ssssssZ). Конечная дата должна быть не раньше начальной даты. Должна быть указана полная точность, разделитель долей секунды "." (точка), должен быть включен индикатор пояса UTC Z UTC, и все отметки времени должны быть в часовом поясе UTC. Представление YYYY-MM-DDT24:00:00.000000Z не следует использовать, вместо этого следует использовать представление YYYY-MM-DDT00:00:00.000000Z.

      5.15 Обратная совместимость

5.15.1 Кодировка значений для передачи

Стандарт CDMI версии 1.0.1 ввел концепцию кодировки значений для передачи, чтобы обеспечить опции хранения и получения произвольных бинарных данных через операции с типом содержимого CDMI. Объекты данных, созданные клиентами CDMI 1.0 посредством операций с типом содержимого CDMI, должны использовать кодировку "utf-8", а объекты, созданные другими операциями, должны использовать кодировку "base64".

Значения полей объектов данных в кодировке base64 не должны быть доступны клиентам CDMI 1.0 через операции с типом содержимого CDMI. Попытка чтения значения таких объектов должна возвращать таким клиентам пустой результат (" "). Клиенты CDMI 1.0 могут выявить такую ситуацию: в этом случае метаданные cdmi_size не равно 0, а значение поля пустое.

5.15.2 Опции экспорта контейнера

CDMI версии 1.0.2 упорядочивает имена опций, которые использует клиентом для определения, может ли контейнер экспортироваться через различные протоколы. Следующие имена опций экспорта контейнера более недействительны:

- cdmi_cifs_export,

- cdmi_nfs_export,

- cdmi_iscsi_export,

- cdmi_occi_export.

      6 Обычные операции

      6.1 Обзор

Все примеры, приведенные в настоящем стандарте, не являются нормативными.

Данный раздел включает примеры следующих типизованных операций СDMI:

- определение опций провайдера облачного хранилища (см. 6.2),

- создание нового контейнера (см. 6.3),

- создание нового объекта данных (см. 6.4),

- получение списка содержимого контейнера (см. 6.5),

- чтение содержимого объекта данных (см. 6.6),

- чтение только значения объекта данных (см. 6.7),

- удаление объекта данных (см. 6.8).

      6.2 Определение опций провайдера облачного хранения

Пример - Выполнение GET к URI, по которому сервер публикует перечень опций:

GET /cdmi_capabilities/ HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-capability

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-capability

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-capability",

"objectID" : "00007E7F0010CEC234AD9E3EBFE9531D",

"objectName" : "cdmi_capabilities/",

"parentURI" : "/",

"parentID" : "00007E7F0010DCECC805FB6D195DDBCB",

"capabilities" : {

"cdmi_domains" : "true",

"cdmi_export_nfs" : "true",

"cdmi_export_webdav" : "true",

"cdmi_export_iscsi" : "true",

"cdmi_queues" : "true",

"cdmi_notification": "true",

"cdmi_query" : "true",

"cdmi_metadata_maxsize" : "4096",

"cdmi_metadata_maxitems" : "1024",

"cdmi_size": "true",

"cdmi_list_children" : "true",

"cdmi_read_metadata" : "true",

"cdmi_modify_metadata" : "true",

"cdmi_create_container" : "true",

"cdmi_delete_container" : "true"

},

"childrenrange" : "0-3",

"children" : [

"domain/",

"container/",

"dataobject/",

"queue/"

]

}

      6.3 Создание нового контейнера

Пример - Выполнение PUT с URI нового контейнера:

PUT /MyContainer/HTTP/1.1

Host: cloud.exampie.com

Accept: application/cdmi-container

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

}

}

Будет получен следующий ответ.

HTTP/1.1 201 Created

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-container",

"objectID" : "00007E7F00102E230ED82694DAA975D2",

"objectName" : "MyContainer/",

"parentURI" : "/",

"parentID" : "00007E7F0010128E42D87EE34F5A6560",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/container/",

"completionStatus" : "Complete",

"metadata" : {

              "cdmi_size" : "0"

},

"childrenrange" :" ",

"children" : [

]

}

      6.4 Создание объекта данных в контейнере

Пример - Выполнение PUT с URI нового объекта данных:

PUT /МуContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain",

"metadata" : {

},

"value" : "Hello CDMI World!"

}

Будет получен следующий ответ.

HTTP/1.1 201 Created

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-object",

"objectID" : "00007E7F0010BD1CB8FF1823CF05BEE4",

"objectName" : "MyDataObject.txt",

"parentURI" : "/MyContainer/",

"parentID" : "00007E7F00102E230ED82694DAA975D2",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/dataobject/",

"completionStatus" : "Complete",

"mimetype" : "text/plain",

"metadata": {

                "cdmi_size" : "17"

}

}

      6.5 Список содержимого контейнера

Пример - Выполнение GET с URI контейнера:

GET/MyContainer/ HTTP/1.1

Host: cloud.example.com

Accept: */*

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-container",

"objectID" : "00007E7F00102E230ED82694DAA975D2",

"objectName" : "MyContainer/",

"parentURI" : "/",

"parentID" : "00007E7F0010128E42D87EE34F5A6560",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/container/",

"completionStatus" : "Complete",

"metadata" : {

             "cdmi_size" : "83"

},

"childrenrange" : "0-0",

"children" : [

              "MyDataObject.txt"

]

}

      6.6 Чтение содержимого объекта данных

Пример - GET по URI объекта данных:

GET /МуContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"objectType": "application/cdmi-object",

"objectID": "00007E7F0010BD1CB8FF1823CF05BEE4",

"objectName": "MyDataObject.txt",

"parentURI": "/MyContainer/",

"parentID" : "00007E7F00102E230ED82694DAA975D2",

"domainURI": "/cdmi_domains/MyDomain/",

"capabilitiesURI": "/cdmi_capabilities/dataobject/",

"completionStatus": "Complete",

"mimetype": "text/plain",

"metadata": {

                "cdmi_size": "17"

},

"valuetransferencoding": "utf-8",

"valuerange": "0-16",

"value": "Hello CDMI World!"

}

      6.7 Чтение только значения объекта данных

Пример - Выполнение GET с URI объекта данных:

GET /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Будет получен следующий ответ.

НТТР/1.1 200 ОK

Content-Type: text/plain

Hello CDMI World!

      6.8 Удаление объекта данных

Пример - Выполнение DELETE с URI объекта данных:

DELETE /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 204 No Content

      7 Стандарт интерфейса

      7.1 Коды состояния HTTP

Коды состояния HTTP (см. таблицу 6) используются для передачи результата операций REST и выполнения базовой семантики HTTP с минимальной перегрузкой. Другие коды состояния HTTP не являются частью настоящего стандарта и сохраняют оригинальную семантику HTTP 1.1.

Таблица 6 - Коды состояния HTTP

Код состояния	Имя HTTP	Описание
200	ОK	Запрос завершился успешно.
201	Created	Ресурс успешно создан.
202	Accepted	Длительная операция принята на выполнение.
204	No Content	Операция завершилась успешно, никаких данных не возвращено.
302	Found	Ресурс является ссылкой на другой ресурс.
400	Bad Request	Содержание запроса неверное или отсутствует.
401	Unauthorized	Неверные данные аутентификации/авторизации.
403	Forbidden	У клиента недостаточно прав для выполнения запроса.
404	Not Found	Ресурс не найден по указанному URI.
406	Not Acceptable	На данном URI не может быть создано содержание, соответствующее запросу.
409	Conflict	Операция конфликтует блокировкой, установленной протоколом доступа, отличным от CDMI , или может вызвать ошибку изменения состояния сервера.

      7.2 Ссылки на объект

Ссылки на объект - это URI в пространстве имен облачного хранилища, переадресующие на другой URI в том же или другом пространстве имен облачного хранилища. Ссылки подобны символическим ссылкам файловой системы. Облако не гарантирует, что URI, на который дана ссылка, будет корректен после создания ссылки.

Ссылки отображаются как дочерние элементы контейнера и отличаются от других объектов завершающим символом "?" в имени. Выполнение операции (за исключением создания или удаления) по URI ссылки приведет к переадресации HTTP 302 Found; поле заголовка Location будет содержать URI назначения, указанный в момент создания ссылки. URI назначения ссылки не должен меняться после создания ссылки.

Для продолжения операции после получении переадресации 302 Found клиент CDMI должен повторить запрос с использованием URI, содержащегося в заголовке Location.

Операция удаления по URI ссылки должна удалить ссылку. Ссылки не могут обновляться. Для обновления адреса назначения клиент должен вначале удалить имеющуюся ссылку, а затем создать новую с желаемым адресом назначения переадресации.

Пример - Применение GET к URI, где URI - ссылка:

GET  /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 302 Found

Location: http://cloud.example.com/MyContainer/MyOtherDataObject.txt

Ссылки на ID объекта должны всегда переадресовывать на URI, завершающийся тем же ID, что и URI запроса.

Пример - Применение GET к URI объекта по ID, где URI - ссылка:

GET /cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 302 Found

Location: http://archive.example.com/cdmi_objectid/00006FFD0010AA33D8CEF9711E0835CA

      8 Операции с ресурсами объекта данных

      8.1 Обзор

Объекты данных - основной компонент хранения в системе CDMI

, аналогичный файлам в файловой системе. Каждый объект данных состоит из набора определенных полей, включающих:

- единственное значение (value)

- опциональные метаданные, генерируемые системой облачного хранения и/или пользователем системы.

Объекты данных в CDMI могут адресоваться двумя способами:

- по имени (например, http://cloud.example.com/dataobject);

- по ID объекта (например, http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E).

Каждый объект данных включает единственный, глобально-уникальный идентификатор объекта (ID), который остается неизменным на протяжении времени жизни объекта. Каждый объект данных имеет один или несколько адресов URI, позволяющих обращаться к объекту.

Каждый объект данных имеет родительский объект, от которого он наследует метаданные, которые не заданы явным образом для рассматриваемого объекта. Так, объект "budget.xls", хранящийся по следующему URI, наследует метаданные системы данных своего родительского контейнера "finance":

http://cloud.example.com/finance/budget.xls

Для доступа к отдельным полям объекта данных необходимо указать имя поля после символа "?", добавляемого к URI объекта данных. Например, следующий URI возвращает значение поля value в сообщении-ответе:

http://cloud.example.com/dataobject?value

Кодировка данных, передаваемых из поля value объекта данных, определяется значением поля valuetransferencoding этого объекта.

Если кодировка значения установлена в "utf-8", данные в поле value объекта должны быть корректной строкой UTF-8, и должны передаваться в поле value как строка UTF-8.

Если кодировка значения установлена в "base64", данные в поле value объекта могут быть произвольной бинарной последовательностью и должны передаваться как строка в кодировке base 64.

Отдельный диапазон значения объекта может быть получен указанием диапазона байтов после имени поля. Например, следующий URI возвращает первые 1000 байт поля value:

http://cloud.example.com/dataobject?value:0-999

Так как диапазон байтов строки UTF-8 не всегда является корректной строкой UTF-8, ответ на запрос с обозначенными границами диапазона передается как строка в кодировке base 64. Аналогично, при изменении диапазона байтов значения поля объекта, содержимое поля должно передаваться как строка в кодировке base 64.

Диапазон байтов включает границы диапазона, как указано в п.14.35.1 RFC 2616.

Допускается указание списка уникальных полей, разделенных символом ";", что позволяет обратиться к нескольким полям в одном запросе. Например, следующий URI возвращает поля value и metadata в сообщении-ответе:

http://cloud.example.com/dataobject?value;metadata

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

8.1.1 Метаданные объекта данных

Метаданные объекта данных могут также включать произвольные метаданные, определенные пользователем, и метаданные системы данных, см. гл.16. Метаданные следует хранить как корректную строку UTF-8. Бинарные данные, сохраненные в пользовательских метаданных, должны быть вначале перекодированы таким образом, чтобы их можно было включить в корректную строку UTF-8; рекомендуется использовать кодировку base 64.

8.1.2 Согласованность объекта данных

Запись в объект данных является атомарной операцией.

Если клиент читает данные из объекта одновременно с операцией записи данных в тот же объект, чтение должно возвращать либо старое значение, либо новое, но не их смесь.

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

Метка времени, возвращенная в ответ на запись, показывает, была ли запись последней операцией (то есть, запись, результат которой будет возвращен при последующем чтении, пока не произойдет новая запись). Если метка времени, возвращаемая при записи, показывает более позднее время, чем метка времени для другой записи, тогда запись с более поздней меткой становится той, чьи данные находятся в объекте в настоящее время, если записи происходят одновременно.

Записи в диапазон могут привести к промежутку в значении объекта, не содержащему записанных данных. Чтение из промежутка с отсутствующими данными должно выдавать нуль в каждом прочитанном байте.

Реализации настоящего стандарта должны обеспечивать атомарность операций, описанных в данном разделе, если объекты данных обрабатываются через CDMI. Атомарность свойств объектов, обрабатываемых по другим протоколам, выходит за рамки настоящего стандарта

8.1.3 Представления объекта данных

В данном разделе используется нотация JSON. И клиенты, и серверы должны поддерживать представление UTF-8 JSON. В теле сообщения-запроса и сообщения-ответа поля объекта JSON могут обозначаться или возвращаться в любом порядке, за исключением (в случае их наличия) полей valuerange и value объекта данных, которые должны появляться последними и в указанном порядке.

      8.2 Создание объекта данных с использованием типа содержимого CDMI

8.2.1 Обзор

Для создания нового объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>

Создание нового объекта по ID, см. 9.9.

где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных уже существующих контейнеров, с наклонной чертой "/", разделяющей каждую пару контейнеров.

- <DataObjectName> имя создаваемого объекта данных.

После создания к объекту можно обращаться как <root URI>/cdmi_objectid/<objectlD>.

8.2.2 Отложенное завершение создания

В ответ на операцию создания объекта сервер может вернуть код 202 Accepted, указывающий на то, что объект находится в стадии создания. Этот ответ полезен в случае длительных операций (например, копирование большого объекта данных из URI источника). Этот ответ имеет следующие последствия:

- сервер вернет заголовок Location с URI создаваемого объекта вместе с кодом HTTP 202 Accepted;

- код 202 Accepted от сервера означает, что были пройдены следующие проверки:

- пользователь авторизован создавать объект;

- пользователь авторизован считывать любые источники, которые должны быть скопированы, перемещены, сериализованы или десериализованы

- доступно достаточно места для создания объекта, или, по крайней мере, достаточно места, чтобы создать URI и сообщение об ошибке.

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

Клиент выполняет операции GET по указанному URI для отслеживания хода выполнения операции. В ответ сервер возвращает два поля в теле сообщения-ответа, указывающие на состояние процесса:

- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо сообщение об ошибке, начинающееся с "Error";

- опциональное поле percentComplete, содержащее процент выполнения операции (от 0 до 100).

GET не должен возвращать никакого значения в объект, если его статус не completionStatus = "Complete". Если конечный результат операции создания - ошибка, то создается URI с полем completionStatus, содержащим сообщение об ошибке. Удаление URI после обнаружения ошибки - обязанность клиента.

8.2.3 Опции

Следующие опции перечисляют операции, которые могут выполняться при создании нового объекта данных:

- поддержка функции создания нового объекта данных обозначена наличием в родительском контейнере опции cdmi_create_dataobject;

- если создаваемый объект - ссылка в родительском контейнере, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_create_reference;

- если новый объект должен быть копией существующего объекта, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_copy_dataobject;

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

- если создаваемый объект - результат операции десериализации исходного объекта, поддержка этой функции обозначена наличием в родительском контейнере опции cdmi_deserialize_dataobject;

- если новый объект - результат операции сериализации, поддержка этой функции обозначена присутствием в родительском контейнере опций cdmi_serialize_dataobject, cdmi_serialize_container, cdmi_serialize_domain или cdmi_serialize_queue.

8.2.4 Заголовки запроса

Заголовки запроса HTTP для создания объекта CDMI с типом содержимого CDMI приведены в таблице 7.

Таблица 7 - Заголовки запроса для создания объекта данных CDMI с типом содержимого CDMI

8.2.5 Тело сообщения-запроса

Поля запроса на создание объекта с использованием типа содержимого CDMI приведены в таблице 8.

Таблица 8 - Тело сообщения-запроса - создание объекта данных с использованием типа содержимого CDMI

Имя поля	Тип	Описание	Требование
mimetype	Строка JSON	Тип данных MIME, содержащихся в поле value объекта данных   Данное поле может добавляться при создании по значению, также при сериализации, десериализации, копировании или перемещении объекта данных.   Данное поле должно храниться как часть объекта.   Если данное поле не указано, ему должно быть присвоено значение "text/plain".   Это поле не должно добавляться при создании ссылки.   Перед сохранением значение типа MIME должно быть преобразовано в нижний регистр.	Опционально
metadata	Объект JSON	Метаданные объекта данных   Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта данных, его значение заменяет метаданные из URI источника.   Если данное поле не включается при десериализации, сериализации, копировании или перемещении объекта данных, должны использоваться метаданные URI источника.   Если данное поле включается при создании нового объекта данных по передаваемому значению, значение данного поля должно быть использовано как метаданные.   Если данное поле не включается при создании нового объекта данных по значению, данному полю должен быть присвоен пустой объект JSON (т.е., "{}").   Данное поле не должно включаться при создании ссылки.	Опционально
domainURI	Строка JSON	URI домена-владельца   Если домен-владелец не совпадает с родительским доменом, пользователь должен иметь права cross_domain privilege (см. cdmi_member_privileges в таблице 64).   Если не указано иное, должен использоваться домен родительского контейнера.	Опционально
deserialize	Строка JSON	URI сериализованного объекта данных CDMI, который должен быть десериализован в создаваемый объект данных	Опционально
serialize	Строка JSON	URI объекта CDMI, который должен быть сериализован в создаваемый объект данных	Опционально
copy	Строка JSON	URI объекта данных или очереди CDMI, которые должны быть скопированы в создаваемый объект данных	Опционально
move	Строка JSON	URI существующего локального или удаленного объекта данных CDMI (URI источника), который должен быть перенесен в URI, указанного в команде PUT. Содержимое объекта, включая ID, должно при перемещении сохраняться, а объект по URI источника должен быть удален после успешного создания нового объекта.   Если недостаточно прав для чтения объекта данных по URI источника, записи объекта по URI назначения или удаления объекта данных по URI источника, или если любая из этих операций не завершена успешно, операция перемещения должна вернуть состояние ошибки 400 Bad Request, а исходный и новый объект должны остаться неизменными.	Опционально
reference	Строка JSON	URI объекта данных CDMI, на который должна быть создана ссылка. Если при создании ссылки предоставляются какие-либо другие поля, сервер должен вернуть сообщение об ошибке HTTP 400 Bad Request.	Опционально
deserialize- value	Строка JSON	Объект данных, сериализованный в соответствии с гл.15 и кодированный с использованием правил base 64 (см. RFC 4648).	Опционально
valuetransfer- encoding	Массив JSON строк JSON	Кодировка, использованная значения объекта данных*. Определены два значения кодировки.   "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться как строка UTF-8 в поле value,   "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле value как строка в кодировке base 64. Задание содержимого поля value объекта данных иное, чем корректная строка в кодировке base 64, должно возвращать клиенту ошибку 400 Bad Request. Данное поле должно включаться лишь при создании объекта по значению. Если иное не указано клиентом, сервер должен установить значение поля valuetransferencoding равным "utf-8".   Данное поле должно храниться как часть объекта.	Опционально
value	Строка JSON	Значение объекта данных   Если данное поле не включено, ему должна быть присвоена пустая строка (те.,"").   Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON (RFC 4627).   Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 (RFC 4648).	Опционально
В каждой отдельной операции должно указываться лишь одно из этих полей. За исключением value, эти поля не должны храниться. Если имеется более одного такого поля, сервер должен вернуть сообщение об ошибке 400 Bad Request.

8.2.6 Заголовки ответа

Заголовки HTTP ответов на создание объекта с использованием типа содержимого CDMI указаны в таблице 9.

Таблица 9 - Заголовки ответа - создание объекта данных с использованием типа содержимого CDMI

8.2.7 Тело сообщения-ответа

Поля тела сообщения-ответа на создание объекта данных с использованием типа содержимого CDMI приведены в таблице 10.

Таблица 10 - Тело сообщения-ответа - создание объекта данных с использованием типа содержимого CDMI

8.2.8 Статус ответа

Коды состояния HTTP, возникающего при создании объекта данных с использованием типа содержимого CDMI, перечислены в таблице 11.

Таблица 11 - Коды состояния HTTP - создание объекта данных с использованием типа содержимого CDMI

8.2.9 Примеры

Примеры

1 Применение PUT к URI контейнера: имя объекта данных и текстовое содержимое:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain",

"metadata" : {

},

"value" : "This is the Value of this Data Object"

}

Будет получен следующий ответ.

HTTP/1.1 201 Created

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-object",

"objectID" : "0000706D0010B84FAD185C425D8B537E",

"objectName" : "MyDataObject.txt",

"parentURI" : "/MyContainer/",

"parentID" : "00007E7F00102E230ED82694DAA975D2",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/dataobject/",

"completionStatus" : "Complete",

"mimetype" : "text/plain",

"metadata" : {

                 "cdmi_size" : "37"

}

}

2 Применение PUT к URI контейнера: имя объекта данных и бинарное содержимое:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain",

"metadata" : { },

"valuetransferencoding" : "base64",

"value" : "VGhpcyBpcyB0aGUgVmFsdWUgb2YgdGhpcyBEYXRhlE9iamVjdA=="

}

Будет получен следующий ответ.

HTTP/1.1 201 Created

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"objectType": "application/cdmi-object",

"objectID": "0000706D0010374085EF1A5C7018D774",

"objectName": "MyDataObject.txt",

"parentURI": "/MyContainer/",

"parentID" : "00007E7F00102E230ED82694DAA975D2",

"domainURI": "/cdmi_domains/MyDomain/",

"capabilitiesURI": "/cdmi_capabilities/dataobject/",

"completionStatus": "Complete",

"mimetype": "text/plain",

"metadata": {

               "cdmi_size": "37"

}

}

      8.3 Создание объекта данных с использованием типа содержимого, отличного от CDMI

8.3.1 Обзор

Для создания объекта данных следует выполнить следующий запрос:

PUT <root URI>/<ContainerName>/<DataObjectName> 2

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число уже существующих промежуточных контейнеров, разделенных наклонной чертой (т.е., "/");

- <DataObjectName> имя создаваемого объекта данных.

После создания к объекту данных можно обращаться как <root URI>/cdmi_objectid/<objectlD>.

8.3.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при создании нового объекта данных:

- поддержка возможности создания нового объекта данных обозначается присутствием опции cdmi_create_dataobject в родительском контейнере.

8.3.3 Заголовки запроса

Заголовки HTTP запроса на создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 12.

Таблица 12 - Заголовки запроса - создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.3.4 Тело сообщения-запроса

Тело сообщения-запроса содержит данные, которые должны храниться как значение объекта данных.

8.3.5 Заголовки ответа

Заголовки ответа не определены.

8.3.6 Тело сообщения-ответа

Поля сообщения-ответа не определены.

8.3.7 Статус ответа

Коды состояний HTTP, возникающих при создании объекта данных с использованием содержимого, отличного от CDMI, описаны в таблице 13.

Таблица 13 - Коды состояния HTTP - создание объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.3.8 Пример

Пример - Применение PUT к URI контейнера: имя объекта данных и содержимое:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Content-Type: text/plain;charset=utf-8

Content-Length: 37

This is the Value of this Data Object

Будет получен следующий ответ.

HTTP/1.1 201 Created

      8.4 Чтение объекта данных с использованием типа содержимого CDMI

8.4.1 Обзор

Для чтения всех полей существующего объекта данных необходимо выполнить следующий запрос:

GET <root URI>/<ContainerName>/<DataObjectName>

Для чтения одного или нескольких полей существующего объекта данных необходимо выполнить один из следующих запросов:

GET <root URI>/<ContainerName>/<DataObjectName>?<fieldname>;<fieldname>;...

GET <root URI>/<ContainerName>/<DataObjectName>?value:<range>;...

GET <root URI>/<ContainerName>/<DataObjectName>?metadata:<prefix>;...

где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных контейнеров.

- <DataObjectName> имя объекта данных, из которого необходимо произвести чтение.

- <fieldname> имя поля.

- <range> диапазон байтов значения объекта данных, которые необходимо вернуть в поле value.

- <prefix> шаблон префикса: возвращаются все метаданные, начинающиеся с данного префикса.

К объекту можно также обратиться как <root URI>/cdmi_objectid/<objectID>.

8.4.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при чтении существующего объекта данных:

- поддержка возможности чтения метаданных существующего объекта данных обозначена наличием опции cdmi_read_metadata у объекта;

- поддержка возможности чтения данных существующего объекта обозначена наличием опции cdmi_read_value у объекта;

- поддержка возможности чтения определенного диапазона байт значения объекта обозначена наличием опции cdmi_read_value_range у объекта.

8.4.3 Заголовки запроса

Заголовки HTTP запросов на чтение объекта данных CDMI, использующего тип содержимого CDMI, приведены в таблице 14.

Таблица 14 - Заголовки запроса - чтение объекта данных CDMI с использованием типа содержимого CDMI

8.4.4 Тело сообщения-запроса

Тело сообщения-запроса должно отсутствовать.

8.4.5 Заголовки ответа

Заголовки HTTP ответа на чтение объекта данных с использованием типа содержимого CDMI приведены в таблице 15.

Таблица 15 - Заголовки ответа - чтение объекта данных CDMI с использованием типа содержимого CDMI

8.4.6 Тело сообщения-ответа

Поля тела сообщения-ответа на запрос чтения объекта данных с использованием типа содержимого CDMI приведены в таблице 16.

Таблица 16 - Тело сообщения-ответа - чтение объекта данных CDMI с использованием типа содержимого CDMI

Если в запрос GET указаны отдельные поля, только эти поля возвращаются в теле ответа. Запрошенные опциональные поля, отсутствующие в объекте, в ответе опускаются.

8.4.7 Статус ответа

Коды состояний HTTP, возникающих при чтении из объекта данных с использованием типа содержимого CDMI, описаны в таблице 17.

Таблица 17 - Коды состояния HTTP - чтение объекта данных CDMI с использованием типа содержимого CDMI

8.4.8 Примеры

Примеры

1 Применение GET к URI объекта данных для чтения всех полей объекта:

GET /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

X-CDMI-Specification-Version: 1.0.2

Content-Type: application/cdmi-object

{

"objectType" : "application/cdmi-object",

"objectID" : "0000706D0010B84FAD185C425D8B537E",

"objectName" : "MyDataObject.txt",

"parentURI" : "/MyContainer/",

"parentID" : "00007E7F00102E230ED82694DAA975D2",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/dataobject/",

"completionStatus" : "Complete",

"mimetype" : "text/plain",

"metadata" : {

              "cdmi_size" : "37"

},

"valuerange" : "0-36",

"valuetransferencoding" : "utf-8",

"value" : "This is the Value of this Data Object"

}

2 Применение GET к URI идентификатора объекта данных для чтения всех полей объекта по ID:

GET /cdmi_objectid/0000706D0010B84FAD185C425D8B537E

HTTP/1.1 Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-object",

"objectID" : "0000706D0010B84FAD185C425D8B537E",

"objectName" : "MyDataObject.txt",

"parentURI" : "/MyContainer/",

"parentID" ; "00007E7F00102E230ED82694DAA975D2",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/dataobject/",

"completionStatus" : "Complete",

"mimetype" : "text/plain",

"metadata" : {

                 "cdmi_size": "37"

},

"valuetransferencoding" : "utf-8",

"valuerange" : "0-36",

"value" : "This is the Value of this Data Object"

}

3 Применение GET к URI объекта данных для чтения полей value и mimetype:

GET /MyContainer/MyDataObject.txt?value;mimetype HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"value" : "This is the Value of this Data Object",

"mimetype" : "text/plain"

}

4 Применение GET к URI объекта данных для чтения первых 11 байт значения объекта:

GET /MyContainer/MyDataObject.txt?valuerange;value:0-10 НТТР/1.1

Host: cloud.example.com

Accept: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"valuerange" : "0-10",

"value" : "VGhpcyBpcyB0aGU="

}

      8.5 Чтение объекта данных с использованием типа содержимого, отличного от CDMI

8.5.1 Обзор

Для чтения значения существующего объекта данных, следует выполнить запрос:

GET <root URI>/<ContainerName>/<DataObjectName>

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число промежуточных контейнеров;

- <DataObjectName> имя объекта данных для чтения.

К объекту возможно обратиться как <root URI>/cdmi_objectid/<objectlD>.

8.5.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при чтении из существующего объекта данных:

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

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

8.5.3 Заголовок запроса

Заголовок запроса HTTP на чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, показан в таблице 18.

Таблица 18 - Заголовок запроса - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.5.4 Тело сообщения-запроса

Тело в сообщении должно отсутствовать.

8.5.5 Заголовки ответа

Заголовки HTTP ответа на чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, показаны в таблице 19.

Таблица 19 - Заголовки ответа - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.5.6 Тело сообщения-ответа

К чтению объекта данных с использованием типа содержимого, отличного от CDMI, предъявляются следующие требования:

- тело сообщения-ответа является содержимым поля value объекта;

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

8.5.7 Статус ответа

Коды состояний HTTP, возникающих при чтении из объекта данных с использованием типа содержимого, отличного от CDMI, описаны в таблице 20.

Таблица 20 - Коды состояний HTTP - чтение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.5.8 Примеры

Примеры -

1 Применение GET к URI объекта данных для чтения значения объекта:

GET /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Будет получен следующий ответ.

НТТР/1.1 200 ОK

Content-Type: text/plain

Content-Length: 37

This is the Value of this Data Object

2 Применение GET к URI объекта данных для чтения первых 11 байт значения объекта данных:

GET /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Range: bytes=0-10

Будет получен следующий ответ.

НТТР/1.1 206 Partial Content

Content-Type: text/plain

Content-Range: bytes 0-10/37

Content-Length: 11

This is the

      8.6 Изменение объекта данных с использованием типа содержимого CDMI

8.6.1 Обзор

Для изменения некоторых или всех полей существующего объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>

Для изменения значения существующего объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>?value:<range>

Для добавления, изменения или удаления определенных метаданных существующего объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>?metadata:<metadataname>;...

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число промежуточных контейнеров;

- <DataObjectName> имя объекта данных для изменения;

- <range> диапазон байт объекта данных для изменения.

К объекту данных возможно обратиться также как <root URI>/cdmi_objectid/<оbjectID>, изменение объекта не должно изменять его ID.

8.6.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при изменении существующего объекта данных:

- поддержка возможности изменения метаданных существующего объекта данных обозначена наличием опции cdmi_modify_metadata у объекта;

- поддержка возможности изменения значения и/или типа MIME существующего объекта данных обозначена наличием опции cdmi_modify_value у объекта;

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

8.6.3 Заголовки запроса

Заголовки HTTP запроса для изменения объекта данных CDMI с использованием типа содержимого CDMI перечислены в таблице 21.

Таблица 21 - Заголовки запроса - изменение CDMI объекта данных с использованием типа содержимого CDMI

8.6.4 Тело сообщения-запроса

Поля тела сообщения-запроса для изменения объекта данных CDMI с использованием типа содержимого CDMI перечислены в таблице 22.

Таблица 22 - Тело сообщения-запроса - изменение CDMI объекта данных с использованием типа содержимого CDMI

Имя поля	Тип	Описание	Требо- вание
mimetype	Строка JSON	Тип MIME данных, содержащихся в поле value объекта данных. При наличии, заменяет существующий тип MIME.   Данное поле может быть включено при изменении по значению, десериализации или копировании объекта данных.   Данное поле должно храниться как часть объекта.   Если данное поле не указано, имеющееся значение поля mimetype должно остаться неизменным.   Данное поле не должно включаться при создании ссылки.   Значение mimetype должно быть преобразовано к нижнему регистру перед сохранением.	Опци- онально
metadata	Объект JSON	Метаданные объекта данных. При наличии, новые метаданные заменяют имеющиеся. Если в URI указан отдельный пункт метаданных, остальные метаданные сохраняются.   Детальное описание метаданных см. в разделе 16.	Опцио- нально
domainURI	Строка JSON	URI домена-владельца   В случае отличия от домена-родителя, пользователь должен иметь права "cross_domain" (см. cdmi_member_privileges в таблице 64).   Если не указано, сохраняется существующий домен.	Опцио- нально
deserialize	Строка JSON	URI сериализованного объекта данных CDMI, который должен быть десериализован для изменения существующего объекта данных. ID сериализованного объекта должен соответствовать ID конечного объекта.	Опцио- нально
copy	Строка JSON	URI объекта данных или очереди CDMI, которые должны быть скопированы в существующий объект данных.	Опцио- нально
deserialize- value	Строка JSON	Сериализованный объект данных (см. гл.15), кодированный по правилам base 64 (RFC 4648). ID сериализованного объекта данных должен соответствовать ID изменяемого объекта.	Опцио- нально
valuetransfer- encoding	Массив JSON строк JSON	Кодировка, использованная при передаче объекта данных. Определены два значения кодировки.   - "utf-8" указывает на то, что объект данных содержит корректную строку UTF-8, и должен передаваться в поле value как строка UTF-8.   - "base64" указывает на то, что объект данных содержит произвольную бинарную последовательность и должен передаваться в поле поля value строкой в кодировке base 64. Задание содержимого поля value объекта данных иное, чем корректная строка в кодировке base 64, должно возвращать клиенту ошибку 400 Bad Request.   Данное поле должно включаться лишь при изменении объекта по значению. Если иное не указано клиентом, сервер должен установить значение поля valuetransferencoding равным "utf-8".   Данное поле должно храниться как часть объекта.	Опцио- нально
value	Строка JSON	Новые данные объекта. При наличии, значение поля заменяет существующее значение.   Если поле valuetransferencoding указывает на кодировку UTF-8, значение должно быть строкой UTF-8, сформированной по правилам JSON (RFC 4627).   Если поле valuetransferencoding указывает на кодировку base 64, значение должно быть вначале кодировано в base 64 (RFC 4648).   Если в запросе указан диапазон, новые данные должны быть вставлены в указанный диапазон. Если при этом возникнут промежутки, они считаются заполненными нулями и должны учитываться при вычислении размера значения. При сохранении диапазона value должно содержать строку в кодировке base 64, и значение поля valuetransferencoding должно быть установлено в "base64".	Опцио- нально
В каждой данной операции должно указываться лишь одно из этих полей. За исключением value, эти поля не должны храниться. Если имеется более одного такого поля, сервер должен вернуть сообщение об ошибке 400 Bad Request.

8.6.5 Заголовок ответа

Заголовок HTTP ответа на запрос изменения объекта данных CDMI с использованием типа содержимого CDMI указан в таблице 23.

Таблица 23 - Заголовок ответа - изменение CDMI объекта данных с использованием типа содержимого CDMI

8.6.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

8.6.7 Статус ответа

Коды состояния HTTP возникающие при изменении объекта данных с использованием типа содержимого CDMI, перечислены в таблице 24.

Таблица 24 - Коды состояний HTTP - изменение CDMI объекта данных с использованием типа содержимого CDMI (лист 1 из 2)

8.6.8 Примеры

Примеры

1 Применение PUT к URI объекта данных для установления новых значений полей:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain",

"metadata" : {

"colour" : "blue",

"length": "10"

},

"value" : "This is the Value of this Data Object"

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

2 Применение PUT к URI объекта данных для изменения типа MIME:

PUT /MyContainer/MyDataObject.txt?mimetype HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"mimetype" : "text/plain"

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

3 Применение PUT к URI объекта данных для изменения диапазона значения:

PUT /MyContainer/MyDataObject.txt?value:21-24 HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"value" : "dGhhdA=="

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

При изменении значения без указания кодировки передачи, клиент должен учитывать текущую кодировку передачи объекта. Если клиент посылает значение строкой UTF-8 для изменения существующего объекта со значением valuetransferencoding равным "base64", должна быть возвращена ошибка. Если клиент отсылает строку base 64 для изменения объекта с valuetransferencoding равным "utf-8", это не должно приводить к ошибке, но приводить к сохранению символьной последовательности без изменений как строки base 64 вместо перекодирования ожидаемых данных в кодировку base 64.

4 Применение PUT к URI объекта данных для замены метаданных:

PUT /MyContainer/MyDataObject.txt?metadata HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

"colour" : "red",

"number" : "7"

}

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

5 Применение PUT к URI объекта данных для добавления новых метаданных и сохранения существующих:

PUT /MyContainer/MyDataObject.txt?metadata:shape HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

"shape" : "round"

}

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

6 Применение PUT к URI объекта данных для замены лишь одного элемента метаданных новым значением:

PUT /MyContainer/MyDataObject.txt?metadata:colour HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-object

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

"colour" : "green"

}

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

      8.7 Изменение объекта данных с использованием типа содержимого, отличного от CDMI

8.7.1 Обзор

Для изменения значения существующего объекта данных следует выполнить запрос:

PUT <root URI>/<ContainerName>/<DataObjectName>

где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных контейнеров.

- <DataObjectName> имя изменяемого объекта данных.

К объекту можно обратиться также как <root URI>/cdmi_objectid/<objectlD>. Изменение не должно изменять ID объекта.

8.7.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при изменении существующего объекта данных:

- поддержка возможности изменения значения существующего объекта и/или типа MIME обозначается присутствием опции cdmi_modify_value у объекта;

- поддержка возможности изменения выбранного диапазона байт значения объекта обозначается наличием cdmi_modify_vaiue_range у объекта.

8.7.3 Заголовки запроса

Заголовки HTTP запроса на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 25.

Таблица 25 - Заголовки запроса - изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.7.4 Тело сообщения-запроса

Тело сообщения-запроса на изменение данных содержит данные для сохранения в значение объекта.

8.7.5 Заголовок ответа

Заголовок ответа HTTP на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведен в таблице 26.

Таблица 26 - Заголовок ответа - изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.7.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

8.7.7 Статус запроса

Коды состояний HTTP, возникающих в ответ на изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI, приведены в таблице 27.

Таблица 27 - Коды состояния HTTP - изменение объекта данных CDMI с использованием типа содержимого, отличного от CDMI

8.7.8 Примеры

Примеры

1 Применение PUT к URI объекта данных для изменения значения объекта данных:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Content-Type: text/plain

Content-Length: 37

This is the value of this data object

Будет получен следующий ответ.

HTTP/1.1 204 No Content

2 Применение PUT к URI объекта данных для изменения четырех байтов в значении объекта данных:

PUT /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

Content-Range: bytes 21-24/37

Content-Type: text/plain

Content-Length: 4

that

        Будет получен следующий ответ.

HTTP/1.1 204 No Content

      8.8 Удаление объекта данных с использованием типа содержимого CDMI

8.8.1 Обзор

Для удаления существующего объекта данных следует выполнить запрос:

DELETE <root URI>/<ContainerName>/<DataObjectName>

где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных контейнеров.

- <DataObjectName> имя удаляемого объекта данных.

К объекту можно также обратиться как <root URI>/cdmi_objectid/<objectlD>.

8.8.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при удалении существующего объекта данных:

- поддержка возможности удаления существующего объекта данных обозначается наличием опции cdmi_delete_dataobject у объекта.

8.8.3 Заголовок запроса

Заголовок HTTP запроса на удаление CDMI объекта с использованием типа содержимого CDMI приведен в таблице 28.

Таблица 28 - Заголовок запроса - удаление CDMI объекта с использованием типа содержимого CDMI

8.8.4 Тело сообщения-запроса

Сообщение-запрос может содержать тело, соответствующее RFC 2616.

8.8.5 Заголовки ответа

Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.

8.8.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

8.8.7 Статус запроса

В таблице 29 приведены коды состояний HTTP, возникающих при удалении CDMI объекта с использованием типа содержимого CDMI.

Таблица 29 - Коды состояния HTTP Status Codes - удаление CDMI объекта с использованием типа содержимого CDMI

8.8.8 Пример

Пример - Применение DELETE к URI объекта данных:

DELETE /MyContainer/MyDataObject.txt HTTP/1.1

Host: cloud.example.com

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 204 No Content

      8.9 Удаление объекта данных с использованием типа содержимого, отличного от CDMI

8.9.1 Обзор

Для удаления существующего объекта данных следует выполнить запрос:

DELETE <root URI>/<ContainerName>/<DataObjectName> Где:

- <root URI> путь к облаку CDMI.

- <ContainerName> неотрицательное число промежуточных контейнеров.

- <DataObjectName> имя удаляемого объекта.

К объекту можно также обратиться как <root URI>/cdmi_objectid/<objectlD>.

8.9.2 Опции

Следующие опции описывают поддерживаемые операции, которые можно выполнять при удалении существующего объекта данных:

- поддержка возможности удаления существующего объекта данных обозначена наличием способности cdmi_delete_dataobject у объекта.

8.9.3 Заголовки запроса

Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.

8.9.4 Тело сообщения-запроса

Сообщение-запрос может содержать тело, соответствующее RFC 2616.

8.9.5 Заголовки ответа

Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.

8.9.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

8.9.7 Статус запроса

Таблица 30 описывает коды состояний HTTP, возникающих при удалении CDMI объекта с использованием типа содержимого, отличного от CDMI.

Таблица 30 - Коды состояний HTTP - удаление CDMI объекта с использованием типа содержимого, отличного от CDMI

8.9.8 Пример

Пример - Применение DELETE к URI объекта данных:

DELETE /MyContainer/MyDataObject.txt HTTP/1.1 Host: cloud.example.com

Будет получен следующий ответ.

НТТР/1.1 204 No Content

      9 Операции с ресурсами вида объект-контейнер

      9.1 Обзор

Объекты-контейнеры - основное средство группировки в CDMI

, аналогичные папкам файловой системы. Каждый объект-контейнер имеет неотрицательное число дочерних объектов и набор полей, включающих стандартизованные и произвольные метаданные. Эти метаданные генерируются облачным хранилищем или задаются пользователем. В модели CDMI контейнеры адресуются двумя способами:

- по имени (например, http://cloud.example.com/container/);

- по ID объекта (например, http://cloud.example.com/cdmi_objectid/0000706D0010B84FAD185C425D8B537E.

Каждый контейнер имеет единственный глобально-уникальный ID, который остается неизменным на протяжении жизненного цикла объекта. Каждый контейнер также может иметь один или несколько адресов URI, что позволяет адресовать контейнеры. Следуя соглашениям об иерархическом пути, URI контейнера должны состоять из одного или нескольких имен контейнеров, разделенных наклонной чертой ("/") и заканчиваться наклонной чертой ("/").

При запросе к ресурсу существующего контейнера, если завершающая наклонная черта в его URI опущена, сервер должен вернуть код состояния HTTP 301 Moved Permanently с заголовком Location, содержащим URI с завершающей наклонной чертой.

При выполнении запроса CDMI на создание нового ресурса контейнера, если опущена завершающая наклонная черта в URI, сервер должен вернуть код состояния HTTP 400 Bad Request.

Запросы вне модели CDMI на создание ресурса контейнера должны включать завершающую URI наклонную черту; в противном случае запрос будет распознан как запрос на создание объекта.

Контейнеры могут быть вложенными.

Пример - Следующий URI указывает на вложенный контейнер:

http://cloud.example.com/container/subcontainer/

Вложенный контейнер имеет родительский объект-контейнер, должен быть включен в поле children контейнера-родителя и наследовать метаданные системы данных и список прав доступа родительского контейнера.

Данная модель позволяет устанавливать прямое соответствие между управляемым CDMI облачным хранилищем и файловыми системами (например, NFSv4 или WebDAV). Если объект-контейнер CDMI экспортируется в файловую систему, файловая система может предоставлять особые механизмы доступа к метаданным CDMI. При создании файлов и папок в файловой системе они становятся видимыми через интерфейс CDMI, служащий путем к данным. Соответствие между конструкциями файловой системы и объектами данных, контейнерами и метаданными CDMI находится за рамками настоящего стандарта.

Для получения отдельного поля объекта контейнера необходимо указать имя поля после знака "?" на конце URI объекта.

Пример - Следующий URI возвращает только поле children в теле сообщения-ответа:

http://cloud.example.com/container/?children

Указанием диапазона после названия поля children можно осуществлять доступ к диапазону поля children.

Пример - Следующий URI возвращает имена первых трех потомков из поля children:

http://cloud.example.com/container/?children:0-2

Диапазоны потомков определяются аналогично диапазону байт, согласно гл.14.35.1 в RFC 2616. Клиент может определить количество потомков запросом поля childrenrange без запроса диапазона потомков.

Возможно указать список полей, разделенных ";", что позволяет обращаться к нескольким полям в одном запросе.

Пример - Следующий URI вернет поля children и metadata в теле сообщения-ответа:

http://cloud.example.com/container/?children;metadata

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

9.1.1 Метаданные контейнера

Могут быть предоставлены следующие опциональные метаданные системы данных (см. таблицу 31).

Таблица 31 - Метаданные контейнера

Метаданные контейнера могут также включать произвольные пользовательские метаданные и метаданные системы данных как описано в разделе 16.

9.1.2 Зарезервированные имена метаданных контейнера

Настоящий стандарт определяет зарезервированные имена контейнеров, которые не должны использоваться при создании новых контейнеров. При попытке создать или контейнер с одним из этих имен сервер должен вернуть клиенту код HTTP 400 Bad Request.*

Зарезервированы следующие имена контейнеров:

- cdmi_objectid;

- cdmi_domains;

- cdmi_capabilities;

- cdmi_snapshots;

- cdmi_versions.

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

9.1.3 Адресация объекта-контейнера

Каждый контейнер может адресоваться одним или несколькими уникальными URI, и все операции должны выполняться через эти URI. Возможны случаи, когда объект-контейнер может доступен* через несколько виртуальных путей. Например, http://cloud.example.com/users/snia/cdmi/ также доступен через http://snia.example.com/cdmi/. Конфликт записи через разные пути должен регулироваться аналогично обработке конфликта записи через один и тот же путь, по принципу возможной связности (см. 9.2).

9.1.4 Представления объекта-контейнера

Представления в данном разделе показаны с использованием нотации JSON. И клиенты, и серверы должны поддерживать UTF-8 представление JSON. В телах сообщений-запросов и ответов, поля JSON могут указываться и возвращаться в любом порядке, за исключением полей childrenrange и children, которые указываются последними и в данном порядке.

      9.2 Создание объекта-контейнера с использованием типа содержимого CDMI

9.2.1 Обзор

Для создания нового объекта-контейнера следует выполнить запрос:

PUT <root URI>/<ContainerName>/<NewContainerName>/

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число уже существующих объектов-контейнеров, разделенных одной наклонной чертой (т.е., "/");

- <NewContainerName> имя нового создаваемого объекта-контейнера.

После создания, к контейнеру можно обращаться как <root URI>/cdmi_objectid/<objectlD>/.

9.2.2 Отсроченное завершение создания

В ответ на запрос создания объекта-контейнера, сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, десериализации исходного объекта данных для создания сложной иерархии объектов). Такой ответ означает, что:

- сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту со статусом HTTP 202 Accepted;

- статус 202 Accepted со стороны сервера удостоверяет, что были пройдены несколько проверок:

- пользователь авторизован для создания нового объекта-контейнера;

- пользователь авторизован для чтения любого исходного объекта, который необходимо переместить, скопировать, сериализовать или десериализовать;

- достаточно места для создания объекта-контейнера или, по крайней мере, достаточно места для создания URI к сообщению об ошибке.

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

Для отслеживания процесса создания клиент выполняет операции GET к URI. В ответ сервер возвращает два поля в теле сообщения-ответа, которые описывают текущее состояние:

- обязательное текстовое поле completionStatus содержит "Processing", "Complete", либо строку сообщения об ошибке, начинающуюся с "Error";

- опциональное поле percentComplete содержит процент выполнения принятого запроса PUT (от 0 до 100). GET не возвращает объектов-потомков контейнера, если completionStatus не равно "Complete".

Если создание объекта завершается с ошибкой, создается URI, а поле completionStatus устанавливается равным сообщению об ошибке. Удаление URI после обработки ошибки возлагается на клиента.

9.2.3 Опции

Следующие опции описывают поддерживаемые операции при создании нового объекта:

- поддержка возможности создания нового объекта-контейнера обозначается наличием опции cdmi_create_container в родительском контейнере;

- если объект, создаваемый в родительском контейнере, является ссылкой, поддержка этой операции обозначается наличием опции cdmi_create_reference в родительском контейнере;

- если новый объект является копией существующего, поддержка копирования обозначается наличием опции cdmi_copy_container в родительском контейнере;

- если новый контейнер создается в результате перемещения, поддержка этой операции обозначается наличием опции cdmi_move_container у родительского контейнера;

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

9.2.4 Заголовки запроса

Заголовки HTTP запросов на создание объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 32.

Таблица 32 - Заголовки запроса - создание объекта-контейнера с использованием типа содержимого CDMI

9.2.5 Тело сообщения-запроса

Поля тела сообщения-запроса на создание объекта-контейнера с использованием типа содержимого CDMI приведены в таблице 33.

Таблица 33 - Тело сообщения-запроса - создание объекта-контейнера с использованием типа содержимого CDMI (лист 1 из 2)

Имя поля	Тип	Описание	Требо- вание
metadata	Объект JSON	Метаданные объекта-контейнера   Если данное поле включено при десериализации, сериализации, копировании или перемещении объекта-контейнера, то значение этого поля должно заменять метаданные URI источника.   Если данное поле не включено при десериализации, сериализации, копировании или перемещении объекта-контейнера, то следует использовать метаданные URI источника.   Если данное поле включено при создании нового объекта по значению, это поле должно быть использовано как метаданные.   Если данное поле не включено при создании нового контейнера по значению, этому полю следует поставить в соответствие пустой объект JSON (т.е., "{}").   Данное поле не должно указываться при создании ссылки на объект-контейнер	Опцио- нально
DomainURI	Строка JSON	URI домена-владельца   В случае отличия от родительского домена, пользователь должен обладать правами cross_domain (см. cdmi_member_privileges в таблице 64).   Если не указано, должен использоваться родительский домен	Опцио- нально
exports	Объект JSON	Структура для каждого из возможных протоколов для данного объекта-контейнера (см. гл.13). Данное поле не должно указываться при создании ссылки	Опцио- нально
Deserialize	Строка JSON	URI сериализованного объекта данных CDMI, который должен быть десериализован при создании нового контейнера, включая всех потомков внутри исходного сериализованного объекта (см. гл.15).   При десериализации контейнера, ни один из экспортированных протоколов исходного сериализованного объекта не должен применяться к вновь создаваемому объекту(ам)	Опцио- нально
сору	Строка JSON	URI объекта-контейнера CDMI, который должен быть скопирован в новый объект-контейнер, включая всех потомков исходного объекта. При копировании объекта-контейнера, экспортированные протоколы не сохраняются в копии	Опцио- нально
move	Строка JSON	URI существующего локального или удаленного объекта-контейнера CDMI (URI источника), который должен быть перемещен, включая все объекты-потомки, в URI, указанный в команде PUT. Содержимое объекта-контейнера и всех потомков, включая ID объекта, должны при перемещении сохраняться (после успешного копирования).   Если недостаточно прав для чтения объекта по URI источника, записи объекта по URI нового объекта, удаления объектов по URI источника или одна из этих операций завершается с ошибкой, сервер должен вернуть код результата 400 Bad Request, причем исходный и конечный объекты должны сохраниться неизменными	Опцио- нально
reference	Строка JSON	URI объекта-контейнера CDMI, на который должна быть сделана переадресация. Если при создании ссылки указаны другие поля, сервер должен вернуть код ошибки 400 Bad Request	Опцио- нально
deserialize- value	Строка JSON	Сериализованный объект-контейнер (см. гл.15), кодированный с помощью base 64 (RFC 4648). ID сериализованного контейнера должен соответствовать ID контейнера-назначения	Опцио- нально
Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться. Если указано более чем одно из этих полей, сервер должен вернуть сообщение об ошибке 400 Bad Request

9.2.6 Заголовки ответа

Заголовки HTTP ответа на создание объекта-контейнера CDMI с использованием типа содержимого CDMI указаны в таблице 34.

Таблица 34 - Заголовки ответа - создание объекта-контейнера с использованием типа содержимого CDMI

9.2.7 Тело сообщения-ответа

Поля тела сообщения-ответа на создание объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 35.

Таблица 35 - Тело сообщения-ответа - создание объекта-контейнера с использованием типа содержимого CDMI

Имя поля	Тип	Описание	Требование
objectType	Строка JSON	"application/cdmi-container"	Обязательно
objectID	Строка JSON	ID объекта	Обязательно
objectName	Строка JSON	Имя объекта	Обязательно
parentURI	Строка JSON	URI родительского объекта   Добавление objectName к parentURI должно всегда давать корректный URI объекта.	Обязательно
parentID	Строка JSON	ID родительского объекта-контейнера	Обязательно
domainURI	Строка JSON	URI домена-владельца	Обязательно
capabilitiesURI	Строка JSON	URI опций объекта	Обязательно
Completion- Status	Строка JSON	Строка, указывающая, находится ли объект в процессе создания, а после завершения операции - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error".	Обязательно
percent- Complete	Строка JSON	Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100.   Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100".   Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100.	Опционально
metadata	Объект JSON	Метаданные объекта-контейнера. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. 16.	Обязательно
exports	Объект JSON	Структура для каждого протокола, разрешенного для данного объекта-контейнера. См. гл.13.	Опционально
snapshots	Массив JSON	Один или несколько URI снимков состояния объектов-контейнеров. См. гл.14.	Опционально
childrenrange	Строка JSON	Потомки контейнера в виде диапазона. При запросе диапазона потомков выдается содержимое этого поля в виде диапазона.	Обязательно
children	Массив JSON	Имена объекто-потомков контейнера. Контейнеры-потомки начинаются символом "/".	Обязательно
Возвращается только при наличии

9.2.8 Статус запроса

В таблице 36 приведены коды состояния HTTP, возникающие при создании объекта-контейнера с использованием типа содержимого CDMI.

Таблица 36 - Коды состояния HTTP - создание объекта-контейнера с использованием типа содержимого CDMI

9.2.9 Пример

Пример - Применение PUT к URI объекта-контейнера: имя и метаданные:

PUT /MyContainer/HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-container

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

},

"exports" : {

"OCCI/iSCSI": {

"identifier": "00007E7F00104BE66AB53A9572F9F51E",

"permissions": [

"http://example.com/compute/0/",

"http://example.com/compute/1/"

]

             },

"Network/NFSv4" : {

"identifier" : "/users",

"permissions" : "domain"

}

          }

}

Будет получен следующий ответ.

HTTP/1.1 201 Created

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-container",

"objectID" : "0000706D0010B84FAD185C425D8B537E",

"objectName" : "MyContainer/",

"parentURI" : "/",

"parentID" : "00007E7F0010128E42D87EE34F5A 6560",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/container/",

"completionStatus" : "Complete",

"metadata" : {

},

"exports" : {

"OCCI/iSCSI" : {

"identifier" : "0000706D0010B84FAD185C425D8B537E",

"permissions" : "00007E7F00104EB781F900791C70106C"

},

"Network/NFSv4" : {

"identifier" : "/users",

"permissions" : "domain"

}

},

"childrenrange" : "",

"children" : [

]

}

      9.3 Создание объекта-контейнера с использованием типа содержимого, отличного от CDMI

9.3.1 Обзор

Для создания нового объекта-контейнера следует выполнить запрос:

PUT <root URI>/<ContainerName>/<NewContainerName>/

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число уже существующих объектов-контейнеров, имена которых разделены символами наклонной черты (т.е., "/");

- <NewContainerName> имя создаваемого контейнера.

После создания к контейнеру можно обращаться как <root URI>/cdmi_objectid/<objectlD>/.

Наличие завершающей наклонной черты в URI, по которому выполняется операция PUT, указывает на создание объекта-контейнера, в отличие от создания объекта данных.

9.3.2 Опции

Следующие опции описывают поддерживаемые операции при создании нового объекта:

- поддержка возможности создания нового объекта-контейнера обозначается наличием опции cdmi_create_container в родительском контейнере.

9.3.3 Заголовки запроса

Сообщение-запрос может содержать заголовки, соответствующие RFC 2616.

9.3.4 Тело сообщения-запроса

Тело запроса должно отсутствовать.

9.3.5 Заголовки ответа

Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.

9.3.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

9.3.7 Статус запроса

В таблице 37 приведены коды состояний HTTP, возникающих при создании объекта-контейнера с использованием типа содержимого, отличного от CDMI.

Таблица 37 - Коды состояний HTTP - создание объекта-контейнера с использованием типа содержимого, отличного от CDMI

9.3.8 Пример

Пример - Применение PUT к URI имени объекта-контейнера:

PUT /MyContainer/ HTTP/1.1

Host: cloud.example.com

Будет получен следующий ответ.

НТТР/1.1 201 Created

      9.4 Чтение объекта-контейнера с использованием типа содержимого CDMI

9.4.1 Обзор

Для чтения всех полей существующего объекта-контейнера следует выполнить запрос:

GET <root URI>/<ContainerName>/<TheContainerName>/

Для чтения одного или нескольких определенных полей существующего объекта-контейнера следует выполнить один из следующих запросов:

GET <root URI>/<ContainerName>/<TheContainerName>/?<fieldname>;<fieldname>;...

GET <root URI>/<ContainerName>/<TheContainerName>/?children:<range>;...

GET <root URI>/<ContainerName>/<TheContainerName>/?metadata:<prefix>;...

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число промежуточных объектов-контейнеров;

- <TheContainerName> имя контейнера для чтения;

- <fieldname> имя поля;

- <range> числовой диапазон в списке потомков;

- <prefix> строковый префикс, будут возвращены все метаданные, начинающиеся с данного префикса.

К контейнеру можно также обратиться как <root URI>/cdmi_objectid/<objectlD>/.

9.4.2 Опции

Следующие опции описывают поддерживаемые операции при чтении существующего объекта-контейнера:

- поддержка возможности чтения метаданных существующего объекта-контейнера обозначается наличием опции cdmi_read_metadata в контейнере;

- поддержка возможности перечисления потомков существующего объекта-контейнера обозначается наличием опции cdmi_Iist_children в контейнере;

- поддержка возможности перечисления диапазона потомков существующего объекта-контейнера обозначается наличием опции cdmi_Iist_children_range в контейнере.

9.4.3 Заголовки запроса

Заголовки HTTP запроса на чтение из объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 38.

Таблица 38 - Заголовки запроса - чтение из объекта-контейнера с использованием типа содержимого CDMI

9.4.4 Тело сообщения-запроса

В запросе должно отсутствовать тело.

9.4.5 Заголовки ответа

Заголовки HTTP ответа для операции чтения объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 39.

Таблица 39 - Заголовки ответа - чтение из объекта-контейнера с использованием типа содержимого CDMI

9.4.6 Тело сообщения-ответа

Поля тела сообщения-ответа для операции чтения объекта-контейнера CDMI с использованием типа содержимого CDMI приведены в таблице 40.

Таблица 40 - Тело сообщения-ответа - чтение объекта-контейнера с использованием типа содержимого CDMI (лист 1 из 2)

Имя поля	Тип	Описание	Требо- вание
objectType	Строка JSON	"application/cdmi-container"	Обяза- тельно
objectID	Строка JSON	ID объекта	Обяза- тельно
objectName	Строка JSON	Имя объекта   Для объектов в контейнере следует вернуть поле objectName.   Для объектов не в контейнере (доступных только по ID), поле objectName не существует и не должно передаваться в ответе	Условно
parentURI	Строка JSON	URI родительского объекта   Для объектов в контейнере следует вернуть поле раrеntURI.   Для объектов не в контейнере (доступных только по ID), поле parentURI не существует и не должно передаваться в ответе.   Добавление objectName к parentURI должно всегда возвращать правильный URI объекта.	Условно
parentID	Строка JSON	ID объекта родительского контейнера   Для объектов в контейнере следует вернуть поле parentID.   Для объектов не в контейнере (доступных только по ID), поле parentID не существует и не должно передаваться в ответе	Условно
domainURI	Строка JSON	URI домена-владельца	Обязательно
capabilitiesURI	Строка JSON	URI опций объекта	Обязательно
completionStatus	Строка JSON	Строка, указывающая, находится ли объект в процессе создания, а после завершения операции - был ли он создан успешно или с ошибкой. Значение должно быть строкой "Processing", "Complete" или строкой, начинающейся с "Error"	Обязательно
percentComplete	Строка JSON	Если значение completionStatus равно "Processing", данное поле, при наличии, должно показывать процент выполнения операции создания объекта, числовым значением от 0 до 100.   Если значение completionStatus равно "Complete", данное поле, при наличии, должно иметь значение "100".   Если значение completionStatus начинается с "Error", данное поле, при наличии, может содержать любое целое число от 0 до 100	Опционально
metadata	Объект JSON	Метаданные объекта-контейнера. Могут включать пользовательские метаданные и метаданные системы данных, указанные в теле запроса на создание (поле metadata) вместе с метаданными системы хранения, создаваемыми облачным хранилищем. Подробнее о метаданных см. гл.16	Обязательно
exports	Объект JSON	Структура каждого протокола, возможного для данного контейнера (см. гл.13)	Опционально
snapshots	Массив JSON	Массив URI снимков состояния объекта-контейнера	Опционально
childrenrange	Строка JSON	Объекты-потомки контейнера в виде диапазона. При запросе диапазона потомков это поле показывает объекты-потомки в форме диапазона.	Обязательно
children	Массив JSON	Имена дочерних объектов контейнера. Имена дочерних объектов не должны содержать зарезервированных символов (см. RFC 3986), например, "%" в имени будет представлен как "%25".   У дочерних объектов, являющихся контейнерами, имя должно заканчиваться символом "/".   У дочерних объектов, являющихся ссылками, имя должно заканчиваться символом "?"	Обязательно
Возвращается только при наличии

Если в запросе GET указаны отдельные поля, в ответе должны быть возвращены только эти поля.

Опциональные запрошенные поля, отсутствующие в объекте, опускаются в ответе.

9.4.7 Статус запроса

Таблица 41 описывает коды состояний HTTP, возникающих при чтении из контейнера с использованием данных типа CDMI.

Таблица 41 - Коды состояний HTTP - чтение объекта-контейнера с использованием типа содержимого CDMI

9.4.8 Примеры

Примеры

1 Применение GET к URI объекта-контейнера для чтения всех его полей:

GET /MyContainer/HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"objectType" : "application/cdmi-container",

"objectID" : "0000706D0010B84FAD185C425D8B537E",

"objectName" : "MyContainer/",

"parentURI" : "/",

"parentID" : "00007E7F0010128E42D87EE34F5A6560",

"domainURI" : "/cdmi_domains/MyDomain/",

"capabilitiesURI" : "/cdmi_capabilities/container/",

"completionStatus" : "Complete",

"metadata" : {

},

"exports" : {

"OCCI/iSCSI": {

"identifier": "00007E7F00104BE66AB53A9572F9F51E",

"permissions": [

"http://example.com/compute/0/",

"http://example.com/compute/1/"

]

},

"Network/NFSv4" : {

"identifier" : "/users",

"permissions" : "domain"

}

            },

"childrenrange" : "0-4",

"children" : [

"red",

"green",

"yellow",

"orange/",

"purple/"

]

}

2 Применение GET к URI объекта-контейнера для чтения parentURI и списка потомков:

GET /MyContainer/?parentURI;children HTTP/1.1

Host: cloud.example.com

Accept: apptication/cdmi-container

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"parentURI" : "/",

"children" : [

"red",

"green",

"yellow",

"orange/",

"purple/"

]

}

3 Применение GET к URI объекта-контейнера для чтения потомков 0..2 и диапазона потомков контейнера:

GET /MyContainer/?childrenrange;children:0-2 HTTP/1.1

Host: cloud.example.com

Accept: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 200 OK

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"childrenrange" : "0-2",

"children" : [

"red",

"green",

"yellow"

]

}

      9.5 Изменение объекта-контейнера с использованием типа содержимого CDMI

9.5.1 Обзор

Для изменения некоторых или всех полей существующего объекта-контейнера следует выполнить запрос:

PUT <root URI>/<ContainerName>/<TheContainerName>/

Для добавления, обновления или удаления определенных элементов метаданных существующего объекта-контейнера следует выполнить запрос:

PUT <root URI>/<ContainerName>/<TheContainerName>/?metadata: <metadataname>;...

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное количество промежуточных контейнеров;

- <TheContainerName> имя изменяемого контейнера.

Объект-контейнер также доступен как <root URI>/cdmi_objectid/<objectlD>/. Обновление объекта не должно изменять его ID.

9.5.2 Отсроченное завершение снимка состояния

Если запрашивается создание снимка состояния (включением поля snap-shot в запрос, см. гл.14), сервер может вернуть код состояния 202 Accepted. Этот ответ предполагает, что:

Сервер удостоверяет, что пройдены определенные проверки:

- пользователь авторизован для создания снимка,

- пользователь авторизован для чтения объекта-контейнера,

- достаточно места для создания снимка или, по крайней мере, достаточно места для создания URI сообщения об ошибке.

Клиент может не получить немедленного доступа к снимку из-за задержек, связанных с использованием в реализации целостности в конечном итоге.

Клиент выполняет запросы GET к URI снимка для отслеживания состояния операции. В частности, сервер возвращает два поля в теле сообщения-ответа:

- текстовое поле completionStatus, содержащее "Processing", "Complete", или сообщение об ошибке, начинающееся с "Error";

- опциональное поле percentComplete, представляющее степень выполнения принятого запроса PUT числом от 0 до 100. Запрос GET не возвращает значения объекта, если completionStatus отлично от "Complete".

Если операция создания снимка завершается ошибкой, создается URI снимка с полем completionStatus, содержащим сообщение об ошибке. Удаление этого URI после обработки ошибки возложено на клиента.

9.5.3 Заголовки запроса

Следующие опции описывают поддерживаемые операции при изменении существующего объекта-контейнера:

- поддержка возможности изменения метаданных существующего объекта-контейнера обозначается наличием опции cdmi_modify_metadata в контейнере;

- поддержка возможности сохранения снимка состояния содержимого существующего объекта-контейнера обозначается наличием опции cdmi_snapshot capability в контейнере;

- поддержка возможности добавления экспортируемого протокола к существующему объекту-контейнеру обозначается наличием опции cdmi_export_<protocol> в контейнере.

9.5.4 Заголовки запроса

Заголовки запроса HTTP для изменения объекта-контейнера CDMI с использованием типа содержимого CDMI перечислены в таблице 42.

Таблица 42 - Заголовки запроса - изменение объекта-контейнера с использованием типа содержимого CDMI

9.5.5 Тело сообщения-запроса

Поля тела запроса операции изменения объекта-контейнера с использованием типа содержимого CDMI перечислены в таблице 43.

Таблица 43 - Тело сообщения-запроса - изменение объекта-контейнера с использованием типа содержимого CDMI

Имя поля	Тип	Описание	Требование
metadata	Объект JSON	Метаданные для объекта-контейнера. Если присутствуют, указанные метаданные замещают существующие метаданные объекта. Если URI указывает на конкретные элементы метаданных, остальные элементы не должны меняться.   Подробнее о метаданных см. раздел 16.	Опционально
domainURI	Строка JSON	URI домена-владельца   В случае отличия от родительского домена, у пользователя должны быть права cross_domain (см. cdmi_member_privileges в таблице 64).   Если не указано, следует использовать родительский домен.	Опционально
snapshot	Строка JSON	Имя создаваемого снимка состояния. Это не URL, а конечный компонент абсолютного URL, где будет находиться снимок после успешного завершения операции создания снимка состояния.   Если снимок добавляется или изменяется, операция PUT возвращает результат лишь после того как снимок добавлен в список снимков. После создания к снимкам можно обращаться как к объектам-потомкам контейнера cdmi_snapshots, вложенного в контейнер, чье состояние снимается.   При создании снимка с тем же именем, что у уже имеющегося снимка, существующий снимок будет заменен.	Опционально
deserialize	Строка JSON	URI сериализованного объекта-контейнера CDMI, который должен быть десериализован для изменения существующего объекта-контейнера.  ID  сериализованного объекта-контейнера должен совпадать с ID объекта-назначения.   Если сериализованный объект-контейнер не имеет потомков, изменение применяется только к объекту-контейнеру, а любые имеющиеся потомки остаются как есть. Если сериализованный объект имеет потомков, тогда операции создания, добавления, изменения и удаления рекурсивно применяются к каждому потомку, в зависимости от различия между представленным сериализованным состоянием и текущим состоянием потомков.	Опционально
copy	Строка JSON	URI объекта-контейнера CDMI, который должен быть скопирован в имеющийся объект-контейнер. Будет скопировано лишь непосредственное содержимое объекта, но не его потомков.	Опционально
deserialize- value	Строка JSON	Сериализованный объект-контейнер (см. гл.15), кодированный с помощью base 64 как описано в RFC 4648.   ID сериализованного объекта-контейнера должно соответствовать ID контейнера-цели. В противном случае сервер должен вернуть состояние 400 Bad Request.   Если сериализованный объект-контейнер не имеет потомков, изменение применяется только к объекту-контейнеру, а любые имеющиеся потомки остаются как есть.   Если сериализованный объект имеет потомков, тогда операции создания, добавления, изменения и удаления рекурсивно применяются к каждому потомку, в зависимости от различия между представленным сериализованным состоянием и текущим состоянием потомков.	Опционально
exports	JSON  Object	Структура для каждого протокола, разрешенного для данного объекта-контейнера (см. гл.13). Если экспортированный протокол добавляется или изменяется, операция PUT возвращается только после завершения операции экспорта.	Опционально
Лишь одно из этих полей должно быть указано в любой из операций. За исключением поля value, данные поля не должны сохраняться.

9.5.6 Заголовок ответа

Заголовок ответа HTTP на изменение объекта-контейнера CDMI с использованием типа содержимого CDMI приведен в таблице 44.

Таблица 44 - Заголовок ответа - изменение объекта-контейнера с использованием типа содержимого CDMI

9.5.7 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

9.5.8 Статус запроса

В таблица 45 приведены коды состояний HTTP, возникающих при изменении объекта-контейнера с использованием типа содержимого CDMI.

Таблица 45 - Коды состояний HTTP - изменение объекта-контейнера с использованием типа содержимого CDMI (лист 1 из 2)

9.5.9 Примеры

Примеры

1 Применение PUT к URI объекта-контейнера для задания новых значений полей:

PUT /MyContainer/ HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"metadata" : {

},

"exports" : {

"OCCI/iSCSI": {

"identifier": "00007E7F00104BE66AB53A9572F9F51E",

"permissions": [

"http://example.com/compute/0/",

"http://example.com/compute/1/"

]

},

"Network/NFSv4" : {

"identifier" : "/users",

"permissions" : "domain"

}

}432   }

Будет получен следующий ответ.

HTTP/1.1 204 No Content

2 Применение PUT к URI объекта-контейнера для установки нового значения экспортируемого протокола:

PUT /MyContainer/?exports HTTP/1.1

Host: cloud.example.com

Content-Type: application/cdmi-container

X-CDMI-Specification-Version: 1.0.2

{

"exports" : {

"OCCI/iSCSI" : {

"identifier" : "0000706D0010B84FAD185C425D8B537E",

"permissions" : "00007E7F00104EB781F900791C70106C"

},

"Network/NFSv4" : {

"identifier" : "/users",

"permissions" : "domain"

}

}

}

Будет получен следующий ответ.

HTTP/1.1 204 No Content

      9.6 Удаление объекта-контейнера с использованием типа содержимого CDMI

9.6.1 Обзор

Для удаления существующего объекта-контейнера, включая все потомки и снимки состояния, следует выполнить запрос:

DELETE <root URI>/<ContainerName>/<TheContainerName>/

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное число промежуточных контейнеров;

- <TheContainerName> имя уничтожаемого объекта-контейнера.

К объекту можно также обратиться как <root URI>/cdmi_objectid/<objectlD>/.

9.6.2 Опции

Следующие опции описывают поддерживаемые операции при удалении существующего объекта-контейнера:

- поддержка возможности удаления существующего объекта-контейнера обозначается наличием опции cdmi_delete_container в контейнере.

9.6.3 Заголовок запроса

Заголовок запроса HTTP для удаления объекта-контейнера CDMI с использованием типа содержимого CDMI приведен в таблице 46.

Таблица 46 - Заголовок запроса - удаление объекта-контейнера с использованием типа содержимого CDMI

9.6.4 Тело сообщения-запроса

Сообщение-запрос может содержать тело, соответствующее RFC 2616.

9.6.5 Заголовки ответа

Заголовки ответа могут быть указаны в соответствии с RFC 2616.

9.6.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

9.6.7 Статус запроса

В таблице 47 приведены коды состояний HTTP, которые могут возникнуть при удалении объекта-контейнера с использованием типа содержимого CDMI.

Таблица 47 - Коды состояний HTTP - удаление объекта-контейнера с использованием типа содержимого CDMI

9.6.8 Пример

Пример - Применение DELETE к URI объекта-контейнера:

DELETE /MyContainer/ HTTP/1.1

Host: cloud.example.com

X-CDMI-Specification-Version: 1.0.2

Будет получен следующий ответ.

HTTP/1.1 204 No Content

      9.7 Удаление объекта-контейнера с использованием типа содержимого, отличного от CDMI

9.7.1 Обзор

Для удаления существующего объекта-контейнера, включая всех потомков и снимки состояния, следует выполнить запрос:

DELETE <root URI>/<ContainerName>/<TheContainerName>/

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное количество промежуточных контейнеров;

<TheContainerName> имя удаляемого объекта-контейнера.

К объекту можно также обратиться как <root URI>/cdmi_objectid/<objectlD>/.

9.7.2 Опции

Следующие опции описывают поддерживаемые операции при удалении существующего объекта-контейнера:

- поддержка возможности удаления существующего объекта-контейнера обозначается наличием опции cdmi_delete_container в контейнере.

9.7.3 Заголовки запроса

Сообщение-запрос может содержать заголовки, соответствующие RFC 2616.

9.7.4 Тело сообщения-запроса

Сообщение-запрос может содержать тело, соответствующее RFC 2616.

9.7.5 Заголовки ответа

Сообщение-ответ может содержать заголовки, соответствующие RFC 2616.

9.7.6 Тело сообщения-ответа

Сообщение-ответ может содержать тело, соответствующее RFC 2616.

9.7.7 Статус запроса

В таблице 48 приведены коды состояний HTTP, которые могут возникнуть при удалении объекта-контейнера с использованием типа содержимого, отличного от CDMI.

Таблица 48 - Коды состояний HTTP - удаление объекта-контейнера с использованием типа содержимого, отличного от CDMI

9.7.8 Пример

Пример - Применение DELETE к URI объекта-контейнера:

DELETE /MyContainer/ HTTP/1.1

Host: cloud.example.com

Будет получен следующий ответ.

НТТР/1.1 204 No Content

      9.8 Создание (POST) нового объекта данных с использованием типа содержимого CDMI

9.8.1 Обзор

Для создания нового объекта данных в заданном контейнере, где имя объекта - идентификатор объекта, присвоенный сервером, следует выполнить запрос:

POST <root URI>/<ContainerName>/

Для создания нового объекта данных в случае, когда объект не принадлежит контейнеру и доступен только по ID (см. 5.8), следует выполнить запрос:

POST <root URI>/cdmi_objectid/

где:

- <root URI> путь к облаку CDMI;

- <ContainerName> неотрицательное количество существующих промежуточных контейнеров, имена которых разделены одиночными наклонными чертами (т.е., "/").

После создания в "/cdmi_objectid/", к объекту данных можно обращаться как <root URI>/cdmi_objectid/<objectlD>.

После создания в контейнере, объект данных доступен как потомок контейнера с именем, присвоенным сервером; к нему также можно обратиться как <root URI>/cdmi_objectid/<оbjectID>.

9.8.2 Отсроченное завершение создания

В ответ на запрос создания объекта данных сервер может вернуть код 202 Accepted, что указывает на то, что объект находится в процессе создания. Это полезно в случае длительных операций (например, копирования большого объема данных от URI источника). Такой ответ означает, что:

Сервер должен вернуть заголовок Location, содержащий URI к создаваемому объекту вместе со статусом HTTP 202 Accepted.