How to Create a HTTP Adapter in IBM Worklight – Legacy Tutorial

IBM Worklight, now part of IBM MobileFirst Platform Foundation, was a leading enterprise mobile platform that simplified building hybrid apps with secure backend integration. One of its core concepts was the adapter model — server‑side components that communicate with external services (REST/SOAP) and expose structured responses to mobile clients.

This guide on javatechig.com explains how to create an HTTP adapter in IBM Worklight step by step, including configuration, procedure implementation, testing, and notes on modern alternatives for today’s development ecosystems.

Note: IBM Worklight/MobileFirst is considered legacy. For new projects, modern backends using Node.js/Spring Boot REST APIs or cloud functions are recommended.

What Is an HTTP Adapter in IBM Worklight?

An HTTP adapter is a server component that:

• Connects to external HTTP/REST web services
• Handles network requests securely
• Transforms backend responses to JSON consumable by mobile apps
• Encapsulates all service logic on the server side

HTTP adapters eliminate direct API calls from apps, centralize security, and avoid CORS issues.

Typical Use Cases

• Fetching remote data (JSON/XML)
• Calling third‑party APIs (weather, social, payments)
• Proxying and caching backend responses
• Applying security/authentication before exposing to apps

Step 1 — Set Up Worklight Project

1. Open IBM Worklight Studio (Eclipse)
2. Create a new Worklight Project
   • File → New → Worklight Project
   • Name: HttpAdapterDemo

Create an application module (e.g., HelloMobile) if not already present.

Step 2 — Create the HTTP Adapter

1. Right‑click the Adapters folder → New → HTTP Adapter
2. In the wizard:
   • Adapter Name: MyHttpAdapter
   • Package: (com.javatechig.adapters)
   • Base URL: (optional, later overridden)
3. Finish the wizard — Worklight will generate:
   • MyHttpAdapter.xml
   • MyHttpAdapter‑impl.js

Step 3 — Configure Environment in XML

Open MyHttpAdapter.xml; configure properties:

<connectivity>
    <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
        <protocol>https</protocol>
        <domain>api.example.com</domain>
        <port>443</port>
        <basePath>/v1</basePath>
    </connectionPolicy>
</connectivity>

• protocol: http/https
• domain: remote API domain
• basePath: base path for endpoints

Step 4 — Define Adapter Procedures

Procedures expose server functions to mobile clients.

Example in MyHttpAdapter‑impl.js:

function getWeather(city) {
    var input = {
        method: 'get',
        returnedContentType: 'json',
        path: 'weather/' + city
    };

    return WL.Server.invokeHttp(input);
}

• method: HTTP method (GET/POST)
• returnedContentType: JSON/XML expected
• path: endpoint path

Step 5 — Deploy the Adapter

1. Right‑click the adapter → Deploy Adapter
2. Open Worklight Console
3. Verify adapter appears and test procedures

You should see the adapter listed with its procedures available in Test view.

Step 6 — Invoke Adapter from Mobile App

In your mobile app’s JavaScript:

var invocationData = {
    adapter: "MyHttpAdapter",
    procedure: "getWeather",
    parameters: ["Delhi"]
};

WL.Client.invokeProcedure(invocationData, {
    onSuccess: function(response) {
        console.log("Weather data:", response.invocationResult);
    },
    onFailure: function(error) {
        console.error("Failed:", error);
    }
});

• "getWeather" calls the adapter procedure
• "Delhi" is passed as an argument to the backend API

Security & Authentication

You can secure adapter procedures using security realms and authenticators:

• Enforce user login
• Token validation
• Role‑based access

In Worklight, configure in authenticationConfig.xml.

Common Errors & Solutions

1. Adapter Not Deploying

Cause: XML syntax or missing connectivity settings
Fix: Validate XML and re‑deploy

2. Wrong Endpoint Path

Cause: Incorrect basePath or path
Fix: Check and adjust paths in adapter config

3. CORS / Network Errors

Cause: Remote API policies
Fix: Adapter acts as proxy — backend CORS not needed

Modern Context (2026): Why This Matters

If you are maintaining legacy enterprise apps, you may still encounter Worklight adapters. However:

Modern alternatives now include:

✔ Backend REST APIs (Node.js/Express, Spring Boot, .NET Core)
✔ Cloud Functions (AWS Lambda, Azure Functions)
✔ API Gateways (NGINX, Kong)
✔ Capacitor/Mobile apps calling REST directly with secure tokens

Using dedicated backend stacks improves scalability, observability, and long‑term maintainability compared to Worklight adapters.

Best Practices (Legacy + Modern)

• Keep adapter logic modular
• Avoid heavy business logic in adapters
• Use caching where possible for remote API calls
• Apply strong authentication and token validation
• Consider migrating to REST microservices when refactoring

Summary

We covered:

• Setting up an HTTP adapter in IBM Worklight
• Configuring connectivity and procedures
• Deploying and testing via Worklight Console
• Invoking adapter from mobile application
• Security considerations
• Modern alternatives for backend services

This legacy HTTP adapter guide on javatechig.com preserves historical relevance while guiding developers maintaining or migrating Worklight‑based systems.