APIs are used for many applications, regardless of platform. In many instances, they are used for integration purposes where the end result of the exchange of data is not for interaction with an application. However, with the rise of mobile device usage, a primary reason for exposing APIs through a community is to encourage and enable development of mobile applications with your content and services.

This chapter introduces and describes IBM mobile strategy and mobile application development using IBM Worklight. In this chapter, an application is referred to as an app.

This chapter contains the following topics:

APIs are a critical part of the development of mobile applications. Although connecting to back-end data sources through integration adapters is possible, mobile application developers increasingly will use REST calls and receive JSON data or XML.

If application development is done internally, then APIs are exposed only internally. Where application development is delegated to a third party, outside the enterprise, the APIs need to be exposed through a management layer.

IBM MobileFirst is an initiative that brings together the tools needed to ensure organizations have a mobile platform that is future-ready. By combining best-in-class development, test, management, integration, security, and analytics tools into a single solution set, the industry-leading MobileFirst portfolio provides clients with a comprehensive and integrated set of products and services to deliver and support their mobile projects. The scope of MobileFirst is shown in Figure 11-1.

Included within the MobileFirst portfolio is IBM API Management and the mobile application platform, IBM Worklight. This chapter introduces IBM Worklight but does not cover any other area within the MobileFirst portfolio.

For IBM MobileFirst portfolio information, see the following website:

The purpose of this book is not to detail the IBM Worklight product. A short overview gives context to the use of APIs and how they can be used in application development.

IBM Worklight is an open, comprehensive, and advanced mobile application platform for smartphones and tablets, helping organizations of all sizes to efficiently develop, test, connect, run, and manage mobile applications.

Worklight Studio, the development environment, is built on Eclipse and enables mobile applications to be built with open technologies such as HTML and JavaScript. JavaScript libraries such as JQuery, Dojo, and Sencha may be included. Worklight provides native shells for the mobile operating systems and the HTML/JavaScript code is then included within the shell for each mobile operating system you want. Thus a mobile application across multiple platforms can be built with a single code base.

With Worklight, you can create a true hybrid application by adding native code and mixing that with the common code base of HTML/JavaScript. With Worklight, you can create web applications, mobile applications that use HTML/JavaScript, hybrid applications that use HTML/JavaScript, and native code or applications that are pure native.

Many of the benefits of Worklight are in the deployment model including security, integration adapters, application management and analytics. Worklight runtime components include a comprehensive API to enable, among other items, offline secure, encrypted data access and simplified geolocation/geofencing capability. Development is greatly enhanced with user tools such as a test capability, enabling test scripts to be defined and run on a mobile device.

Further information and downloads are at the IBM Worklight website:

IBM Worklight consists of five components (see Figure 11-2 on page 257):

Worklight Studio is an Eclipse based development environment making possible the development of the mobile application.

Worklight Server is the gateway between apps, external services, and the enterprise. The server facilitates encrypted communications an integration along with security analytics and operational management functions.

As part of the server, the Worklight Application Center enables enterprises to set up their own internal app store. This supports any Worklight application regardless of the mobile operating system and facilitates the management and testing of pre-release apps and the distribution of production-ready apps.

The Worklight Console is the browser-based interface for the administration of the Worklight Server.

These components include APIs for security, application management, offline data storage, geofencing and more.

Worklight supports application development with HTML, JavaScript, or CSS and native code for the device platform. You can build a hybrid application using both approaches. Regardless of the coding model, a Worklight application will communicate with the Worklight Server, which is typically behind an enterprise firewall and exposed through a secure gateway. Figure 11-3 on page 258 illustrates the reference architecture for IBM Worklight. IBM Worklight adapters are used to communicate with the enterprise service bus and all application development is done in-house. API Management is not featured in the figure. An API Management implementation changes this reference architecture and this is covered in 11.4.1, “Internal and external APIs” on page 258.

Enterprises can use IBM API Management to expose APIs for internal use. This is useful as an abstraction layer for all application development within the enterprise.

Modifying the Worklight reference architecture in Figure 11-3 with API Management gives us two possible topologies:

Where the APIs are internal only, the Worklight HTTP adapter invokes the API. Figure 11-4 on page 259 shows the architecture where APIs are internally exposed and Worklight adapters are used to invoke the API.

Where APIs are exposed externally (Figure 11-5), Worklight adapters are not used to invoke the APIs. This would involve additional unnecessary latency with the call coming into the network only to go out and back into the API Management layer. In this scenario, the mobile application invokes the API calls directly and not though the Worklight Server.

Worklight contains capability for adapters that are used for integration with enterprise applications (also referred to as back-end data systems). These adapters, for IBM Worklight v6.0.0.1, are as follows:

The benefits of using the server-side adapters include security, scalability, and analytics data collection. The HTTP adapter can be used to invoke REST APIs and used for the scenario where APIs are exposed internally only.

Further details are at the following web page:

How an API is invoked depends on the programming language used and the approach taken. An API call is a small, but essential, part of an application.

The common code in Worklight is written with HTML/CSS/JavaScript. Example 11-1 shows a simple JavaScript function to make an XML HTTP request to invoke one of the APIs constructed.

JavaScript frameworks such as Dojo, JQuery, or Sencha have their own syntax and methods for making the calls. Mobile applications using native code call the API differently. The API call in Example 11-1 on page 260 returns JSON data that is shown in Example 11-2.

One benefit of implementing IBM API Management is the capability to build new APIs using the assembly functionality. This is described in 3.4.3, “Creating the Assembly definitions” on page 57.

By creating an assembly, it is possible to aggregate data from more than one data source, whether from existing internal back-end APIs or third-party application calls. The assembly capability also enables the mapping and transformation of data from the back end.

The assembly capability can be designed with specific capability in mind, not only the exposure of existing services and data objects. It can be used to optimize the response ensuring that unnecessary data, such as object metadata, is not returned. Although not sending a few bytes of data to a mobile device might not seem like much, when there are many millions of API calls per month, this can amount to a large quantity of data.

Some back-end services can return data of which 50% is not required by an app.