Блог

Главная - Вопросы по программированию - Вызов API Softlayer (для VirtualGuests) возвращает огромный дублированный ответ

Вызов API Softlayer (для VirtualGuests) возвращает огромный дублированный ответ

#ibm-cloud-infrastructure #jclouds #brooklyn

#ibm-cloud-infrastructure #jclouds #бруклин

Вопрос:

При использовании приведенной ниже команды мы получаем ответ с полезной нагрузкой json размером 145 МБ:

 curl -uuser:api-key https://api.softlayer.com/rest/v3/SoftLayer_Account/VirtualGuests?objectMask=powerState;operatingSystem.passwords;datacenter;billingItem;blockDevices.diskImage;tagReferences
% Total % Received % Xferd Average Speed Time Time Time Current
                           Dload Upload Total Spent Left Speed
12 145M 12 18.0M 0 0 321k 0 0:07:44 0:00:57 0:06:47 401k

Просматривая наши журналы за пару недель назад, тот же звонок дал нам ответ размером примерно ~ 300 КБ. Поэтому мы считаем, что это недавняя ошибка в реализации API Softlayer.

Глядя на ответ json, можно увидеть огромное количество повторений. Сведения о каждой виртуальной машине повторяются 394 раза.

Мы экспериментировали с различными вызовами API и определили обходной путь: использовать tagReferences.tag.name вместо tagReferences :

 curl -uuser:api-key https://api.softlayer.com/rest/v3/SoftLayer_Account/VirtualGuests?objectMask=powerState;operatingSystem.passwords;datacenter;billingItem;blockDevices.diskImage;tagReferences.tag.name
% Total % Received % Xferd Average Speed Time Time Time Current
                           Dload Upload Total Spent Left Speed
100 277k 100 277k 0 0 77421 0 0:00:03 0:00:03 --:--:-- 77426

Мы столкнулись с этой проблемой в Apache Brooklyn, используя jclouds (см. Проблему Brooklyn и обходной путь, добавленный в jclouds в https://github.com/jclouds/jclouds/pull/1020 ). Это по-прежнему будет влиять на те, кто использует существующие версии jclouds GA.

Может ли SoftLayer подтвердить, является ли это ошибкой с их стороны, если и когда она будет исправлена, и есть ли лучший обходной путь?

Ответ №1:

Это не ошибка, потому что вы используете objectMask для извлечения дополнительных данных. В этом случае ссылки на теги отображают «Информацию об объектных отношениях». Вот почему сведения о виртуальной машине повторяются более одного раза. Тем не менее, вы можете управлять этой информацией, как и во втором запросе: tagReferences.tag.name . Кроме того, можно получить более одного атрибута объекта или вложенных атрибутов, например, в этом примере маски:

objectMask=mask[tagReferences[id, tagTypeId,customer[адрес1,город]]]

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

Комментарии:

1. Сначала я отправил запрос в службу поддержки Softlayer — они сказали: «Что касается ваших вопросов по API, вы должны направить его по следующей ссылке, поскольку они смогут лучше помочь вам в этом случае».

2. Повторение каждой виртуальной машины 394 раза кажется очень чрезмерным и удивительным — я не думаю, что это связано только с данными реляционных атрибутов. Пару недель назад мы получали ~ 300 КБ; теперь мы получаем 154 МБ в ответе (без существенного различия количества виртуальных машин). Поэтому я снова обращусь к поддержке Softlayer.

Ответ №2:

Просто наткнулся на эту проблему, не совсем уверен, является ли это ошибкой, но, по крайней мере, это не очевидно: при маскировании tagReferences.tag.name API будет фильтровать дочерний объект tagReferences.tag , но он оставит остальную часть целого tagReferences , которая включает в себя огромный customer объект, содержащий много ненужной информации (включая дочерний hardware ).

Решение, которое я нашел, — фильтровать по любому другому атрибуту, кроме tag , даже если вы его не используете:

  • tagReferences[tag[name]] вернет только name атрибут в tag , но также вернет все атрибуты из tagReferences
  • tagReferences[id,tag[name]] вернет только id и tag.name из tagReferences
Метки: