HTTP Request Configuration Example

A typical use of the HTTP request operation is to consume an external HTTP service using the default GET method.

By default, the GET and OPTIONS methods do not send the payload in the request; the body of the HTTP request is empty.The other methods send the message payload as the body of your request.

After sending a request, the connector receives the response and passes it to the next element in your application’s flow. For more additional info Mule 4 Training

The required minimum setting for the request operation is a host URI, which can include a path. You can configure the following types of authentication in the request operation:

• Basic
• OAuth
• NT LAN Manager (NTLM)
• Digest

Map Between Mule Messages and HTTP Requests

By default, the HTTP request operation sends the Mule message payload as the HTTP request body but you can customize it using a DataWeave script or expression.

Add Custom Parameters

In addition to the body of the request, you can configure:

• Headers
• Query parameters
• URI parameters
• A map of multiple headers or parameters

By default, the HTTP connector limits the HTTP request header section size (request line + headers) to 8191 bytes maximum.

To increase the number of bytes in the allowed header section, set mule.http.headerSectionSize in the wrapper.conf file or on the command line when you start Mule as follows: Learn more skills from Mulesoft Training

./mule -M-Dmule.http.headerSectionSize=16000

Headers

Select Headers in the General configuration to add headers to the request. For example, add header names HeaderName1 and HeaderName2, add header values HeaderValue1 and HeaderValue2.

You can use DataWeave expressions, for example #[{‘HeaderName1’ : ‘HeaderValue1’, ‘HeaderName2’ : ‘HeaderValue2’}].

There are also use cases in which there are a set of default headers you always want to set. For example, you might want to always send authentication headers like x-csrf-token: Fetch.

You can specify default headers at the config level so that you don’t have to specify them on every single request. For example:

<http:request-config name="requestConfig">
    <http:request-connection host="localhost" port="8081" streamResponse="true" responseBufferSize="1024"/>
    <http:default-headers >
        <http:default-header key="x-csrf-token" value="Fetch" />
    </http:default-headers>
</http:request-config>

With this configuration, those headers will be added to every outbound request, alongside any headers you specify in the actual request.

The default headers also accept expressions, allowing you to use dynamic values. For example: Learn practical and programmatic skill from Mule Training

<http:request-config name="requestConfig">
    <http:request-connection host="localhost" port="8081" streamResponse="true" responseBufferSize="1024"/>
    <http:default-headers >
        <http:default-header key="custom-role" value="#[vars.role]" />
    </http:default-headers>
</http:request-config>

This practice is helpful and convenient but has some important caveats to consider. Using expressions in a configuration element constitutes a dynamic configuration.

The lifecycle of a dynamic configuration is not explained here, but in a nutshell, all expressions in the config are evaluated each time the connector is used and for each set of distinct values a new configuration instance is created and initialized.

For the particular case of the HTTP connector, this means that it’s only a good idea to use default headers with expressions when you are certain that the universe of all possible values that those expressions can take is small.

If, on the contrary, it is likely that every single evaluation is going to yield a different value, you’ll end up creating several instances of the HTTP client, which will affect performance (due to the extra work that initializing a client takes) and be resource-consuming.

For such cases, the recommendation is to not use default headers but rather to specify headers on the request operation itself:

<http:request config-ref="requestConfig" method="#[attributes.method]" path="#[attributes.maskedRequestPath]">
	<http:headers>#[{'custom-role':vars.role}]</http:headers>
</http:request>

Query Parameters

In General > Request > Query Parameters, click the plus icon (+) to add a parameter to a request. Type a name and value for the parameter or use a DataWeave expression to define the name and value.

To get in-depth knowledge, enroll for a live free demo on Mulesoft Online Training