Contact Us 1-800-596-4880

HTTP Connector - Mule 4

HTTP Connector v1.5

Anypoint Connector for HTTP (HTTP Connector) enables you to declare HTTP servers that listen to requests and trigger flows, as well as HTTP clients that can communicate with any HTTP service.

HTTP Connector effectively allows you to both expose and consume HTTP based APIs. For example, APIkit and RESTConnect both use the HTTP connector internally to work with APIs.

HTTP Connector also supports HTTPS (TLS) connectivity, provides easy ways to serve static resources and secure servers, and handles a number of client authentication schemes.

Release Notes: HTTP Connector Release Notes
Exchange: HTTP Connector

POM File Information


Replace x.x.x with the version that corresponds to the connector you are using.

HTTP Servers

HTTP servers expose services for users or applications to consume. They receive data in the form of requests and return a response. For the connector, this means triggering flows when a request is received and responding once the flow finishes. This is all handled by the HTTP Listener, a source the connector provides.

HTTP servers are declared by first defining an HTTP Listener connection, which defines the host and port where requests are received.

For example:

<http:listener-config name="serverConfig">
  <http:listener-connection host="localhost" port="8081"/>

In this example, the HTTP Listener configuration is named serverConfig. It listens on a computer’s localhost address (IP address and on port 8081. After you set up a server in Anypoint Studio, you can access this server at the http://localhost:8081 URL.

To fully configure your server, you can choose specific resource paths to execute a flow, so that when a request matching that path is received, Mule runs your flow.

Consider the following example:

<flow name="hello">
    <http:listener path="greet" config-ref="serverConfig"/>
    <set-payload value="Hello, world!"/>

<flow name="bye">
    <http:listener path="exit" config-ref="serverConfig"/>
    <set-payload value="Goodbye, world!"/>

In these examples, two HTTP listeners are set up to use the previous configuration serverConfig that created an HTTP server on the localhost and port 8081. Depending on which path is triggered, different flows will execute.

Thus, calling http://localhost:8081/greet returns Hello, world! while calling http://localhost:8081/exit returns Goodbye, world!.

The received request data is shared with the flow when executed, and the responses can be customized.

The next example uses the incoming HTTP request query parameters and customizes the body of its HTTP responses:

<flow name="hello">
  <http:listener path="greet" config-ref="serverConfig">
        #[payload ++ ' I am an HTTP server.']
  <set-payload value="#['Hello, ' ++ ( default 'world') ++ '!']" />

Considering the example above, now calling http://localhost:8081/greet?name=Ana returns Hello, Ana! I am an HTTP server., while calling http://localhost:8081/greet returns Hello, world! I am an HTTP server..

You can find a complete overview of the HTTP listener features in the HTTP Listener Configuration Reference.

HTTP Clients

HTTP clients enable you to send requests to HTTP services and handle their responses. For the connector, this means executing a request and returning the answer. This is handled by the HTTP request, an operation that the connector provides.

HTTP clients don’t necessarily need to be declared, though declaring them is recommended so you can reuse configurations. If you don’t declare an HTTP client, you need to specify the entire URL each time you want to send a request. Although this configuration is useful for quick requests, if you do several requests on different API resources, it is best to declare the client specifying the host to connect to.

<http:request-config name="clientConfig">
  <http:request-connection host="localhost" port="8081"/>

In this example, the HTTP request configuration is named clientConfig. It sends requests to localhost and port 8081, the previously configured server.

To perform requests, each operation you use only needs to feature the path where it should go.

<flow name="helloAndBye">
  <http:request method="GET" path="greet" config-ref="clientConfig"/>
  <logger level="INFO" message="#[payload]"/>
  <http:request method="GET" path="exit" config-ref="clientConfig"/>
  <logger level="INFO" message="#[payload]"/>

The previous examples consume the service exposed previously by sending requests to greet and exit. When the flow executes, it displays:

Hello, world! I am an HTTP server.
Goodbye, world!

The requests can be customized, and the response data is shared with the flow.

The next example customizes the request sent with query parameters and uses the received HTTP response status:

<flow name="fullHello">
  <http:request method="GET" path="greet" config-ref="clientConfig">
      #[{"name" : "HTTP client"}]
  <logger level="INFO"
   message="#['Received a ' ++ attributes.statusCode ++ ' response with body: {' ++ payload ++ '}']"/>

When this flow executes, it displays:

Received a 200 response with body: {Hello, HTTP client! I am an HTTP server.}

You can find a complete overview of the HTTP request features in the HTTP Request Configuration Reference.

View on GitHub