Відправляє запити HTTP і повертає відповідь на нього (рис.8.1).
рис.8.1. Налаштування вузлу HTTP requests
В якості вхідного значення приймає наступні властивості повідомлень:
url
(string) – якщо не сконфігуроване в вузлі, ця опціональна властивість виставляє url для запиту.method
(string) - якщо не сконфігуроване в вузлі, ця опціональна властивість виставляє метод HTTP для запиту. Повинно бутиGET
,PUT
,POST
,PATCH
абоDELETE
.`headers
(object) – виставляє HTTP заголовки в запитіcookies
(object) – якщо вказані, можуть бути використані для відправки куків з запитомpayload
– виставляє тіло для запитуrejectUnauthorized
– якщо виставлено вfalse
дозволяє робити запити на сайти https, які використовують сертифікати, які підписуються самостійноfollowRedirects
– якщо виставлено вfalse
запобігає наступним перенаправленням (HTTP 301).true
за замовчуванням
На виході формує:
payload
(string/object/buffer) –- тіло відповіді. Вузол може бути налаштований так, щоб повернути тіло у вигляді string, спробувати розпарсити його як рядок JSON або залишити його у вигляді двійкового буфера.statusCode
(number) -- код стану відповіді або код помилки, якщо запит не може бути завершений.headers
(object) –- об’єкт, що містить заголовки відповідейresponseUrl
(string) -- у випадку, якщо під час обробки запиту відбулися будь-які перенаправлення, це властивість є останньою адресою, що переадресовується. В іншому випадку це URL оригінального запиту.responseCookies
(object) -- якщо відповідь включає файли cookie, ця властивість є об'єктом пар імені/значення для кожного cookie.redirectList
(array) -- якщо запит було перенаправлено один або кілька разів, накопичена інформація буде додана до цього ресурсу.location
- наступне місце переадресації.cookies
-- це файли cookie, повернені з джерела переадресації
Якщо сконфігуровано у вузлі, властивість URL може містити теги mustache-style. Вони дозволяють створювати URL, використовуючи значення вхідного повідомлення. Наприклад, якщо URL-адресу встановлено example.com/{{{topic}}}
в це місце буде автоматично додано msg.topic
. Використання {{{...}}}
запобігає вилученню з mustache символів на зразок /
, &
і т.д.
Вузол необов'язково може автоматично кодувати msg.payload
як параметри рядка запиту для GET-запиту, в цьому випадку msg.payload
повинен бути об'єктом.
Примітка: Якщо запускається за проксі-сервері, необхідно встановити стандартну змінну середовища http_proxy=...
і перезапустити Node-RED, або використовувати вузол Proxy Configuration. Якщо було встановлено вузол Proxy Configuration, конфігурація цього вузлу має перевагу перед змінною середовища.
Для того щоб використовувати більше одного з таких вузлів в тому самому потоці, необхідно дотримуватися властивості msg.headers
. Перший вузол встановить цю властивість з заголовками відповіді. Тоді наступний вузол буде використовувати ці заголовки для свого запиту - це звичайно не правильно. Якщо властивість msg.headers
залишається незмінною між вузлами, вона буде ігноруватися другим вузлом. Щоб встановити користувальницькі заголовки, msg.headers
слід спочатку видалити або скинути порожнім об'єктом: {}
.
Властивість cookies
, передана вузлу, повинна бути об'єктом з парою ім'я/значення. Значення для встановлення значення cookie може бути string, або об'єктом з єдиною властивістю value
.
Будь-які файли cookie, повернені запитом, передаються назад у властивості responseCookies
.
Якщо msg.payload
є Object, вузол буде автоматично встановлювати тип контенту запиту в application/json
і кодувати тіло відповідним чином.
Для кодування запиту як форми даних, msg.headers["content-type"]
буде встановлюватися як application/x-www-form-urlencoded
.
Для виконання запиту завантаження файлу, msg.headers["content-type"]
слід встановити на " multipart/form-data
, а msg.payload
, переданий у вузол, повинен бути об'єктом із такою структурою:
{
"KEY": {
"value": FILE_CONTENTS,
"options": {
"filename": "FILENAME"
}
}
}
Значення KEY
, FILE_CONTENTS
та FILENAME
слід встановити у відповідні значення.