Пытаюсь попробовать rest api через google advance rest client
Так вот ругается
{
code: 5
message: “Error: Missing parameter ‘auth_user’”
}
И не пойму почему, auth_user прописан в header
Теперь не знаю как передать json_data
Где его передавать в header? Что указывать в значении?
Что не так?
Нет обязательного параметра json_data. Нужно использовать form-data или urlencoded.
разобрался сам
Разобрались, поделитесь с остальными.
Для того, чтобы задать вопрос конкретному участнику форума, есть система упоминаний: указываем ник пользователя, а перед ним “@”. @John или @vladimir, в этом случает пользователь получит оповещение.
У меня хитрая схема авторизации.
Но если я в браузере имею авторизованную сессию с itop
то вызов rest через google advanced rest client выглядит вот так
1 лайк
Единственное что не работает на картинке это то что я не смог передать через rest привязку к инциденту.
Вроде в ответе видно что привязан запрос, но по факту привязка не происходит
статусы двигаются через Operation: core/apply_stimulus так как указано в документации.
Проверено - работает
Updates one object and applies a stimulus to change the state of the object
Passing the following json_data:
{
“operation”: “core/apply_stimulus”,
“comment”: “Synchronization from blah…”,
“class”: “UserRequest”,
“key”: 15,
“stimulus”: “ev_assign”,
“output_fields”: “friendlyname, title, status, contact_list”,
“fields”:
{
“team_id”: 18,
“agent_id”: 57
}
}
Привязка делается не через ref или friendlyname (это просто текстовые поля), а через поля id, в вашем случае parent_incident_id. И передавать надо не строку типа “I-00001234”, а целое число 1234, которое является уникальным идентификатором объекта.
В ответе parent_incident_id: 0.
Точно!
Спасибо
Новая задача, можно ли получить данные из истории запроса через rest?
А также можно ли получить данные истории запроса через OQL?
История изменений объекта тоже является объектом (вернее, группой объектов) и может быть получена через OQL запрос и REST. При каждом обновлении тикета создается один объект класса CMDBChange и несколько связанных с ним объектов CMDBChangeOp (посмотрите эти классы в модели данных). Кол-во и реальный класс объектов CMDBChangeOp зависит от того, какие поля были изменены (для каждого типа поля свой дочерний класс CMDBChangeOp).
Можно написать длинный запрос и вытащить все данные, но получить историю в удобочитаемом виде просто через OQL и REST не получится. Мне видится два варианта. Первый - обработать полученные данные на клиентской стороне. Второй - добавить в REST интерфейс новую операцию “core/history”, которая будет принимать id объекта, обрабатывать его историю как на вкладке “История” и возвращать уже обработанные данные.
Друзья, возникла таже проблема, но картинок не хватает, толи мозга)) Как это починить?
Могу только с rest-клиентом помочь) Кидай картинку с параметрами своими.