API layer

A REST or Web services API layer offers a decoupled interface to data and/or functionality of one or more applications. It provides a common, language-agnostic way of interacting with an application. Web services APIs offer a well-defined contract, called WSDL, that describes the services in terms of its operations and the data types used to exchange information. REST APIs don't typically have this contract; instead, they are documented with client libraries for most common languages including Ruby, Java, PHP and JavaScript. SOAP Web services have traditionally been adopted in the enterprise for publishing internal services as well as for exchanging information with partners in B2B transactions. On the Web, REST is the preferred way of publishing an API and we are now seeing this influence enterprise behavior.

Use cases

Here are some common examples of where an API layer would be used:

• You need to connect to a legacy application that does not have a REST API. For example, you have a custom CRM or HR system that you want employees to be able to access through a portal.
• You want to publish an API that enables your partners to communicate with your systems through a well-defined interface. Typically a Web services API is created for this.
• You want to connect to multiple applications or data sources, combine the data and send the results to your mobile application. For example, you might want to enrich HR or customer information with data available on social networks like Facebook or LinkedIn. In another common scenario, you might have multiple CRM systems but want to provide a unified view to anyone accessing customer data on the road.

Let's expand on a mobile use case that interacts with an enterprise application.

Mobile application integration

Once you have made the decision to develop either a native (iOS/Android) or HTML-based application for your mobile device, the next major challenge is how to integrate this application with your backend applications such as your CRM or ERP system.

The unique presentation challenges faced by mobile application developers have fundamentally changed the way we create web applications. Previously, HTML would be requested from a central server and rendered in "browsers" at the client side. The new "mobile app" model involves the delivery of dynamic content using HTTP and AJAX, with communication taking the form of JSON data being passed over HTTP using REST services.

Consequently, the integration challenge becomes how to quickly expose your existing infrastructure to this new "mobile delivery channel," while minimizing changes to your backend infrastructure. Organizations that are able to achieve this quickly will be able to expose their traditional business models to entirely new devices and demographics. Mule provides significant value here by providing a simple mechanism, or mediation layer, between existing SOAP/XML-based Web services and REST/JSON applications. Additionally, you can easily orchestrate sophisticated composite applications from multiple backend services, both REST and non-REST services, without the need to expose your internal object model to your external consumers.

Implementation

In this use case, we will show how easy it is using Mule to "RESTify" an existing application. By "RESTify" we mean creating a REST Web service frontend to an existing application.

Let's say you wanted to enable your sales team to create a new sales opportunity from their mobile devices that:

• Is synchronized with your Salesforce CRM implementation and
• Sends an email notification to a manager if the opportunity is over a certain dollar value.

REST

The REST API and JSON data format allow more languages and devices easier access to the backend systems.

Salesforce

Salesforce is used to query data for our application. Mule provides pre-built connectivity to Salesforce, including bulk and streaming APIs.

SMTP

This application sends email alerts. Mule's modular architecture makes it easy to send messages to a wealth of technologies including Apple Push, Android Notifications and Twilio (SMS).

Integration core principles

Applying the five core integration principles below, a mobile application integration use case typically involves the following:

Transformation

Since we are going to consume this interface from a mobile application, the best choice for the data format is JSON, which is a protocol that is very easy to work with both in a mobile application and in Mule. In this case the challenge will be to transform the JSON data being received from our mobile device into a format that can be loaded in SFDC. A simple JSON data object is presented below, which indicates the type of data being received from our mobile application.

Transportation

Transport protocol negotiation between a REST-based service that interacts with our mobile application and in our use case, with the SFDC system over HTTP and an additional email connection that uses the SMTP protocol.

Orchestration

Composing several underlying components into a single higher order composite service. In this use case, we are aggregating an update with SFDC with a simple email service and presenting it as a REST-based mobile application using a simple Mule integration flow to wire everything together.

Mediation

Mediation will be useful here over time as it becomes necessary to support multiple versions of this service for a wide range of consumers. Additionally, it is possible (if required) to provide an additional SOAP interface for this REST-based service by simply adding the mediation components to marshal between SOAP/XML & JSON.

Non-functional consistency

These requirements are by nature generic and include providing a common implementation of security, logging, deployment, management of run-time components and more. Mule provides functionality to cater to each of these requirements

Mule integration components

Mule provides a simple graphical interface for composing these types of applications. The first step in communicating with a mobile application would be to use an HTTP endpoint coupled with a REST component. This step takes care of most of the complexity associated with communicating with your mobile apps and consuming JSON objects. Mule also simplifies the process of communicating with the Salesforce CRM system by providing a "pre-built" cloud connector. You simply drag the connector into your project, specify your user name and token, select the function that you want to call and you're done. Likewise, the process of adding filtering logic and communicating with an SMTP server for sending email is also greatly simplified.

The following project has been built using Mule Studio.

Summary

So what have we accomplished? Using Mule we've illustrated how easy it can be to leverage your existing applications and compose them into higher level REST services, which makes integrating with mobile applications easy.

Further, we've also shown how simple it is using the pre-built connector provided by Mule to integrate between mobile applications and Salesforce. This is a significant achievement when you consider that integration is one of the primary challenges faced by companies adopting cloud technologies such as SFDC.

Mobile devices have opened up delivery channels to much wider audiences and demographics. Mule allows you to respond to the new interaction models required by these devices and easily integrates with your existing systems in a simple, scalable and reliable manner.

Learn More

Expand your knowledge of API layers by learning API security best practices.