The configuration patterns series continues with this new installment!
We’re happy to announce that a new configuration pattern made its way into Mule 3.3. This new pattern, named HTTP Proxy, will come in handy when remote web resources need to be accessed in a controlled manner, for example when it is not desirable to have numerous internal applications depend directly on external services.
It also supports caching, which allows you to reduce the outbound traffic towards regularly (and of course cacheable) web resources.
Core Features
Very much like its cousin the Web Service Proxy, the HTTP Proxy sits in the middle between a caller application and a target web resource. It propagates HTTP requests and responses, including their headers.
Typical use cases for this configuration pattern include:
- exposing a remote web resource as one being hosted behind a corporate firewall,
- adding or removing HTTP headers,
- dynamically dispatching to different remote resources,
- content caching of regularly accessed resource.
As you can see in the following examples, configuring the HTTP Proxy is trivial:
The configuration patterns are now located in the http://www.mulesoft.org/schema/mule/pattern namespace (whose location is http://www.mulesoft.org/schema/mule/pattern/3.3/mule-pattern.xsd). Referring to the pre-existing patterns (WS Proxy, Bridge, Simple Service and Validator) is still possible in their own namespaces but the approach is deprecated and it is recommended to switch to the pattern namespace as soon as possible.
Inbound and outbound endpoints can either be specified as full URI address attributes, endpoint reference attributes or child elements. When using the address attributes, it is possible to define transformers for the request and response phases with attributes too (as shown hereafter), otherwise transformers have to be configured within the endpoint elements.
Like all the other configuration patterns, the HTTP Proxy supports inheritance, which enables re-use of common configuration elements. In the following example, the transformers configuration is shared between an abstract parent and a concrete implementation:
More concrete implementations, with different addresses, could then be created.
Path Extension
The HTTP Proxy automatically propagates the path extension received on the inbound endpoint to the path of the outbound endpoint.
This means that, within the context of the previous examples, if a request for http://localhost:8080/acme-data/extra/stuff.txt is sent to the proxy, it will be forwarded as http://acme.org/feeds/data/extra/stuff.txt.
Similarly, query parameters are propagated so, http://localhost:8080/acme-data?id=123 would then become http://acme.org/feeds/data?id=123.
Dynamic Dispatch
Path extension is a convenient mechanism but requires the sender to know about the URL structure of the remote service. Thanks to its support of the Mule Expression Language, the HTTP Proxy can generate outbound addresses based on any expression that can be evaluated on the the in-flight message.
Take a look at the following example:
When interacting with this proxy, the caller application will have to provide an HTTP header named X-Acme-Feed that will be used in order to build the actual outbound address. More complex expressions can be created to implement more complex dynamic dispatch rules.
Caching
Caching is a way to save already-processed data in order to avoid the cost of reprocessing the same request multiple times.
To use caching, the HTTP Proxy must reference a caching strategy – the HTTP caching strategy (EE), for example – that uses the HTTP caching directives to determine how to cache each response .
Take a look at the following example:
As always, your feedback and suggestions are welcome: please share them as comments to this post or in the forum.
