PATCH Request

This node can be used to issue a HTTP PATCH requests. A PATCH request is considered a set of instructions on how to modify a resource. Contrast this with PUT; which is a complete representation of a resource.

The node allows you to either send a request to a fixed URL (which is specified in the dialog) or to a list of URLs provided by an optional input table. Every URL will result in one request which in turn will result in one row in the output table. You can define custom request headers in the dialog.

The sent data is usually taken from a column of the input table but you can also provide a constant value in the dialog instead.

By default the output table will contain a column with the received data, its content type, and the HTTP status code. The node tries to automatically convert the received data into a KNIME data type based on its content type. In case no automatic conversion is possible, binary cells will be created.
You can extract additional response headers into column by defining them in the dialog.

The node supports several authentication methods, e.g. BASIC and DIGEST. Other authentication methods may be provided by additional extensions.

The node supports the Credential port as input (see dynamic input ports). If the port is added, it must supply a Credential that can be embedded into the HTTP Authorization header, and all request done by the node will use the Credential from the port, regardless of other node settings. The OAuth2 Authenticator nodes provide such a Credential for example.

Options

Connection

URL: Select a constant URL or a column from the input table that contains the URLs that you want to request.
Handling of invalid URLs: Specifies how invalid URLs are handled. Depending on the selected mode, this node either inserts missing values as responses, fails the node execution on encountering the first invalid URL, or omits such rows from the output. The latter option filters rows based on URL validity of the URL column. For REST client nodes, all URLs conforming to RFC 1738 and using the HTTP or HTTPS protocol are considered valid.
Delay (ms): Here you specify a delay between two consecutive requests, e.g. in order to avoid overloading the web service.
Concurrency: Number of concurrent requests
Ignore hostname mismatches: If checked, the node trusts the server's SSL certificate even if it was generated for a different host.
Trust all certificates: If checked, the node trusts all certificates regardless of their origin or expiration date.
Follow redirects: If checked, the node will follow redirects (HTTP status code 3xx).
Send large data in chunks: Specifies whether HTTP Chunked Transfer Encoding is allowed to be used by the node. If enabled, messages with a large body size are being sent to the server in a series of chunks.
Timeout (s): Timeout for a single request in seconds
Body: Name of the response body column in the output table

Authentication

Type: The authentication type, e.g. no authentication, BASIC, or DIGEST
Use credentials: Uses the selected credentials instead of username and password provided in the dialog.
Username: The username used for authentication.
Password: The corresponding password used for authentication.

Proxy

Direct connection (no proxy): This option disables the proxy for this PATCH node. This will bypass KNIME-wide proxies as well.
Use KNIME-wide proxy settings: Uses the same proxy as the KNIME platform. In the KNIME Analytics Platform, this can be changed under File > Preferences > General > Network Connections.
Use node-specific proxy settings: This option enables the configuration fields in the "Proxy" tab. The proxy settings apply only to this PATCH node.
Proxy Protocol: This option describes the proxy protocol to use. HTTP, HTTPS and SOCKS can be selected.
Proxy Host: Specifies the proxy host address.
Proxy Port: Specifies the port that should be used at the proxy host.
Workflow Credentials: If enabled, this option allows to select credentials stored in the workflow to be used for the username and password. Filling the "Username" and "Password" fields is not needed then.
Username: If the option "Proxy host needs authentication" is enabled, this field specifies the username to use. Always uses Basic authentication for proxy hosts.
Password: If the option "Proxy host needs authentication" is enabled, this field specifies the password to use. Always uses Basic authentication for proxy hosts.
Excluded Hosts: If the option "Exclude hosts from proxy" is enabled, this field specifies the hosts that will be ignored by the proxy connection. Requests to excluded hosts will use a direct connection. If multiple hosts are specified, they should be separated using a vertical bar ('|').

Error Handling

Fail on connection problems (e.g. timeout, certificate errors, …): This option describes what should happen if there was a problem establishing the connection to the server. The node either fails in execution or outputs status code and error message in the corresponding row.
Server-side errors (HTTP 5XX): These options describe what should happen if a response with a 5XX status code is received. These status codes usually describe errors on the server side.
Client-side errors (HTTP 4XX): These options describe what should happen if a response with a 4XX status code is received. These status codes usually describe client-side errors such as an incorrect web address.
Fail node execution or output missing value: This option describes what should happen after a request has failed. The node either fails in execution or outputs a missing value in the row of the output table that corresponds to this request. This option can be set separately for server- and client-side errors.
Retry on error: Specifies whether the node should retry a request if the initial request received a response indicating a server-side error.
Number of retries: The maximum number of retries to perform for server errors (count does not include the initial request).
Retry delay: The delay to apply between the first request and the first retry. For each subsequent retry, the delay is doubled.
Rate-limiting error (HTTP 429): This status code can be returned by a server to indicate that the rate of incoming requests has been too high.
Pause execution: In case of a rate-limiting error, wait for the set amount of time before retrying the request. Note that this delay is static and does not increase with subsequent attempts, neither does it count as retries for server-side errors.
Output additional column with error cause: If enabled, each output row corresponding to a request will contain an additional cell that, in case the request has failed, will provide a description of the error cause. If the request was successful, the cell will contain a missing value.

Request Headers

Merge: If you click this button the request headers from the selected template on the left are merged with the already existing header definitions in the table below.
Replace: If you click this button the request headers from the selected template on the left will replace any existing header definitions in the table below.
Header key: The HTTP header key, e.g. Accept or X-Custom-Key. Note that some header keys such as Origin are silently ignored by default for security reasons. You can configure KNIME AP to allow any header key by setting the sun.net.http.allowRestrictedHeaders system property in the knime.ini configuration file to true.
Header value: The value for the header which can be a constant value or a reference to a flow variable, a column, a credential name, or a credential password (see the kind option).
Header kind: The kind of the value specified, which is either a constant value or a reference to a flow variable, a column, a credential name, or a credential password.
Fail on missing header value: Setting this option makes the node fail once a header input value is not available anymore, e.g. due to a missing value. Is enabled by default.

Request Body

Use column's content as body: Use the selected column's content as the body of the request.
Use constant body: Use the specified content below as the body of the request.

Response Headers

Extract all fields: If checked, all header fields present in the first response are extracted into columns.
Header key: The name of the header to extract.
Header type: The KNIME data type the header should be converted into.

Input Ports

: Optional data table containing the variable parameters of the requests.
…: A Credential, that can be embedded into the HTTP Authorization header. If this port is added, then all request done by the node will always use the Credential from the port, regardless of other node settings. The OAuth2 Authenticator nodes provide such a Credential for example.

Output Ports

: Data table containing columns from the responses.

Popular Predecessors

Popular Successors

Views

This node has no views

Workflows

Developers

You want to see the source code for this node? Click the following button and we’ll use our super-powers to find it for you.

Installation

To use this node in KNIME, install the extension KNIME REST Client Extension from the below update site following our NodePit Product and Node Installation Guide:

v5.3

A zipped version of the software site can be downloaded here.

Plugin provider: KNIME AG, Zurich, Switzerland

Plugin version: 5.3.3.v202410291554

On NodePit since: 2024-07-09

Last update: 2024-11-15

Tags: Streamable

KNIME versions: Since v4.3

Deploy, schedule, execute, and monitor your KNIME workflows locally, in the cloud or on-premises – with our brand new NodePit Runner.

Try NodePit Runner!