ГОСТ Р ИСО/МЭК 19831—2017
Пример
Пример сценария создания (2) с использованием MachineTemplate по ссылке:
{ "resourceURI": "
http://schemas.dmtf.Org/cimi/1/MachineCreate"
,
"п а т е ~myMachine456",
“
description": "Машина подключена к сущ ествующему тому",
"machineTemplate": {
"h re r: "
http://example.com/MachineTemplates.f72000
",
Credential": {"h re r: "
http://example.com/m yCredentiar}
"networklnterfaces
/
{ "addresses": [{“address": {"h re r: "
http://example.com/addresses/add4"}},
{"address": {"h re f: "
http://example.com/addresses/add5"}}
],
"network": {"href": "
http://example.com/networks/net1"},
"state": "ACTIVE"}
]
}
}
В данном примере создана новая машина, названная "myMachine456". которая также связана с
существующей сетью Network, как и в примере (1). но с иной совокупностью адресов Addresses. В на
стоящем примере во время создания присваиваются значения двум видам атрибутов:
- установка атрибута уровня экземпляра Ресурса: эти атрибуты должны быть незамедлительно
обновлены в созданном Ресурсе, в данном случае пате и description;
- переопределение атрибутов Шаблона: MachineTemplate. на который указывает ссылка, исполь
зуется для создания Machine, но атрибут Credential в этом Шаблоне переопределен учетными данны ми.
предоставленными в запросе создания, также как и массив networklnterfaces. В случае, если такие
атрибуты не присутствовали в Шаблоне по ссылке, их добавляют (временно) только для создания этого
экземпляра Machine.
Некоторые запросы на создание допускают передавать конфигурационные параметры Ресурсов
по ссылке или по значению, например Credential в операции создания Machine. Правила обработки,
определенные выше, применяют также и в этих случаях.
Если ответ имеет код статуса 201, то ответ должен включать в себя:
- заголовок HTTP Location со ссылкой на новый Ресурс.
Если ответ на запрос включает в себя сериализацию нового Ресурса, то ответ должен дополни
тельно содержать:
- заголовок HTTP Content-Type;
- заголовок HTTP Content-Length.
Например ответ может быть следующим:
НТТР/1.1 201 CreatodLocation: <местоположение>
Content-Type: application/(json|xml)
Content-Length: <дпина>
<свриализация нового ресурса>
4.2.1.3 Обновление ресурса
Для обновления состояния Ресурса по адресу editURI, заданного для этого типа Ресурса, направ
ляют запрос PUTHTTP. содержащий полное обновленное представление. Потребители должны вклю
чать в запрос PUT все непустые атрибуты Ресурса, включая те. которые они. возможно, не поддержи вают
или не понимают, которые возвращались в ответе GET. Это нужно для того, чтобы гарантировать, что
клиент не изменяет (стирает) непреднамеренно данные в Ресурсе, исключив их из полного пред
ставления Ресурса.
Во многих случаях данный editURI совпадает с URI самого Ресурса. При получении представле
ние Ресурса должно включать в себя операцию «edit», содержащую editURI. который должен использо
ваться. если запрашивающей стороне разрешено изменять Ресурс.
Если при обработке запроса PUT сервер обнаруживает, что предпринимается попытка обновить
атрибут, предназначенный только для чтения или неизменяемый атрибут, он должен проигнорировать
этот запрос обновления атрибута, не генерируя сообщения об ошибке. Это правило также относится к
частичному обновлению Ресурса.
Из-за потенциальных конфликтов, которые могут произойти вследствие нескольких параллель
ных обновлений. Потребители должны использовать механизм частичного обновления, определенный
в 4.2.1.3.1, чтобы уменьшить возможности ошибочного обновления атрибутов устаревшими данными.
14