node-red/packages/node_modules/@node-red/nodes/locales/de/network/21-httprequest.html

99 lines
6.4 KiB
HTML

<!--
Copyright JS Foundation and other contributors, http://js.foundation
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<script type="text/html" data-help-name="http request">
<p>Senden von HTTP-Anforderungen und Rückgabe der Antwort.</p>
<h3>Eingangsdaten</h3>
<dl class="message-properties">
<dt class="optional">url <span class="property-type">string</span></dt>
<dd>Wenn nicht im Node eingestellt, setzt diese optionale Eigenschaft die URL der Anforderung.</dd>
<dt class="optional">method <span class="property-type">string</span></dt>
<dd>Wenn nicht im Node eingestellt, setzt diese optionale Eigenschaft die HTTP-Methode der Anforderung
(<code>GET</code>, <code>PUT</code>, <code>POST</code>, <code>PATCH</code> oder <code>DELETE</code>).</dd>
<dt class="optional">headers <span class="property-type">object</span></dt>
<dd>HTTP-Header der Anforderung.</dd>
<dt class="optional">cookies <span class="property-type">object</span></dt>
<dd>Wenn gesetzt, kann es verwendet werden, um Cookies mit der Anforderung zu senden.</dd>
<dt class="optional">payload</dt>
<dd>Hauptteil der Anforderung.</dd>
<dt class="optional">rejectUnauthorized</dt>
<dd>Wenn auf <code>false</code> gesetzt, können Anforderungen an https-Sites gesendet werden, die selbst signierte Zertifikate verwenden.</dd>
<dt class="optional">followRedirects</dt>
<dd>Wenn auf <code>false</code> gesetzt, wird ein nachfolgendes Redirect (HTTP 301) verhindert.
Standard ist <code>true</code>.</dd>
<dt class="optional">requestTimeout</dt>
<dd>Wenn dieser Wert auf eine positive Zahl eingestellt ist,
wird damit der global eingestellte Parameter <code>httpRequestTimeout</code> überschrieben.</dd>
</dl>
<h3>Ausgangsdaten</h3>
<dl class="message-properties">
<dt>payload <span class="property-type">string | object | buffer</span></dt>
<dd>Hauptteil der Antwort.<br/>
Der Node kann eingestellt werden, um den Hauptteil als String zurückzugeben,
zu versuchen, ihn als JSON-String zu analysieren oder ihn als binären Puffer (buffer) zu belassen.</dd>
<dt>statusCode <span class="property-type">number</span></dt>
<dd>Statuscode der Antwort oder der Fehlercode, wenn die Anforderung nicht abgeschlossen werden konnte.</dd>
<dt>headers <span class="property-type">object</span></dt>
<dd>Objekt mit dem HTTP-Header der Antwort.</dd>
<dt>responseUrl <span class="property-type">string</span></dt>
<dd>Falls während der Bearbeitung der Anforderung Umleitungen aufgetreten sind, ist diese Eigenschaft die letzte umgelenkte URL.
Andernfalls die URL der ursprünglichen Anforderung.</dd>
<dt>responseCookies <span class="property-type">object</span></dt>
<dd>Wenn die Antwort Cookies enthält, ist dieses Element ein Objekt von Name/Wert-Paaren für jedes Cookie.</dd>
</dl>
<h3>Details</h3>
<p>Wenn innerhalb des Nodes eingestellt, kann die URL-Eigenschaft
<a href="http://mustache.github.io/mustache.5.html" target="_blank">mustache-style</a>-Tags enthalten.
Diese ermöglichen es, die URL aus den Werten der eingehenden Nachricht aufzubauen.
Wenn die URL beispielsweise <code>example.com/{{{topic}}}</code> lautet,
wird der Wert von <code>msg.topic</code> automatisch eingefügt.
Die Verwendung von {{{...}} hindert Mustache am Escaping von Zeichen wie z.B. / & usw.</p>
<p><b>Hinweis</b>: Wenn Node-RED hinter einem Proxy läuft, sollte die Umgebungsvariable <code>http_proxy=...</code>
gesetzt und Node-RED neu gestartet werden.
Alternativ kann eine Proxy-Konfiguration verwendet werden, die dann Vorrang vor der Umgebungsvariable hat.</p>
<h4><b>Verwendung mehrerer HTTP-Anforderungs-Nodes</b></h4>
<p>Um mehr als einen dieser Nodes im gleichen Flow verwenden zu können,
ist Aufmerksamkeit bei der Verwendung der <code>msg.headers</code>-Eigenschaft gefordert.
Der erste Node setzt diese Eigenschaft mit dem Antwort-Header.
Der nächste Node verwendet dann diesen Header für seine Anfrage, was aber nicht die richtige Art und Weise ist.
Wenn die <code>msg.headers</code>-Eigenschaft zwischen den Nodes unverändert bleibt, wird sie vom zweiten Node ignoriert.
Um benutzerdefinierte Header festzulegen, sollte <code>msg.headers</code> zuerst gelöscht oder
auf ein leeres Objekt gesetzt werden: <code>{}</code></p>
<h4><b>Behandlung von Cookies</b></h4>
<p>Die an den Node übergebene <code>cookies</code>-Eigenschaft muss ein Objekt von Name/Wert-Paaren sein.
Der Wert kann entweder ein String sein, um den Wert des Cookies zu setzen,
oder es kann ein Objekt mit einer einzigen <code>value</code>-Eigenschaft sein.<p>
<p>Alle auf Anforderung zurückgegebene Cookies werden über die <code>responseCookies</code>-Eigenschaft zurückgegeben.</p>
<h4><b>Behandlung von Content-Typen</b></h4>
<p>Wenn <code>msg.payload</code> ein Objekt ist, setzt der Node automatisch den Inhaltstyp der Anforderung
auf <code>application/json</code> und kodiert den Hauptteil als solchen.</p>
<p>Um die Anforderung als Formulardaten zu kodieren, sollte <code>msg.headers["content-type"]</code> auf
<code>application/x-wwww-form-urlencoded</code> gesetzt werden.</p>
<h4><b>Datei-Upload</b></h4>
<p>Um einen Datei-Upload umzusetzen, sollte <code>msg.headers["content-type"]</code> auf <code>multipart/form-data</code>
gesetzt werden und das an den Node zu sendende <code>msg.payload</code> muss ein Objekt mit folgender Struktur sein:</p>
<pre><code>{
"KEY": {
"value": FILE_CONTENTS,
"options": {
"filename": "FILENAME"
}
}
}</code></pre>
<p>Die Inhalte von <code>KEY</code>, <code>FILE_CONTENTS</code> und <code>FILENAME</code>
sollten auf passende Werte gesetzt sein.</p>
</script>