Объекты-контейнеры - основное средство группировки в 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 - Метаданные контейнера
Имя метаданных | Тип | Описание | Требование |
cdmi_assignedsize | Строка JSON | Число байт, которые передаются через внешние протоколы (например, устройство может использовать тонкую инициализацию). Это число может ограничивать cdmi_size. | Опционально |