Basics of HTTP Connector

This presentation gives a basic understanding of the HTTP Connector in MuleSoft.

Transcript

1. HTTP Connector Basics - MuleSoft -- Narasimhan Chenduru
2. Agenda  What is a connector?  When to use HTTP connector?  Requestor  Listener  The various parameters  Challenges faced
3. What is a connector?  Development with MuleSoft is made easy primarily because of the plethora of connectors.  An connector can be considered as an encapsulated functional block, which takes in input and performs a specific action.  Connectors are generally used to integrate or interact with the external resources.  Most of them are available on the Anypoint Exchange.
4. The HTTP Connector  The HTTP connector is one of the most commonly used connector.  This connector is polymorphic in nature and the functionality depends on where the connector is used in a flow.  The prime purpose of the connector is to invoke the external APIs by means of the REST protocol.  It can also be used to listen to the incoming requests on a specific address, and act accordingly.  There are instance when we can make a SOAP call also using the REST approach, but the Web Service Consumer is generally used for this purpose.
5. HTTP Listener  The HTTP Connector when used as an input of the flow, acts as a listener.  In such cases, the Mule service runs on a specified address and port and the flow is invoked whenever any hit is received on that address.  The listener is used in order to expose a service using Mulesoft.  The listener expects a message at the end to be provided as the response of the above exposed service.  The listener would generally not take any input parameters. The only structural change compared to the Requester is that the reference would be ‘http-listener- config’. Sample xml structure : <http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="8081" doc:name="HTTP Listener Configuration"/>
6. HTTP Request  The HTTP Request Configuration is used in scenarios where MuleSoft is invoking an external API.  The HTTP Connector when used in the non-source / input part of the flow acts as the requestor.  In case of the Request config, the payload or the message prior to the flow invocation becomes the body of the request (in case of methods such as POST).  Sample XML structure of the config: <http:request-config name="HTTP_Request_Configuration" host=“test-service.com" port=“443" doc:name="HTTP Request Configuration"/>
7. Parameters Listener : • The path is the relative to the base path present in the Connector Config. • Allowed methods include : GET, POST, PUT, DELETE,etc • In case any Headers are to be added, use the ‘Add Header’ • Status code : filters out the response based on the status code.
8.  Connector config : This refers to the reference of the http configuration. It contains details as shown below : This has details such as the host name, the path to be used, port number. In case of any self signed certificates, and use of trust store, use this tab.
9.  Request config : • Path : relative to the base path • Method : the method used when making the callout • Parameters: the header to be included, the query params, the URI params, etc. Note that the payload becomes the body of the callout in case of methods such as POST.
10.  Request config reference: • Almost similar to the one in Listener, but has differences in the Authentication Tabs, the Proxy config.
11. Authentication : • Contains the various modes of authorizations possible. Choosing a mode such as Basic would ask for the credentials, while the OAuth flows would ask for the client tokens and secrets to perform the OAuth dance.
12. Challenges faced :  The rest configuration is pretty straightforward and easy to use.  Couple of things to note when working in constrained environments are as follows:  Setting the proxy configuration.  Use of spring properties such as SSLType in environments where a specific SSL is enabled.  If the development is done on a higher version of Mule and the code is deployed on to a backward version then the callout might fail owing to addition of new headers.  As a good practice, ensure that the status codes are set to 0..599 when developing the flows. This enables us to debug the flow better, instead of receiving an exception.