In working with many Worklight clients, the question around direct REST Service calls vs. Worklight Adapters comes up often. REST services began its life as consumable services that can be invoked by Rich Internet Applications using an Ajax pattern. With Mobile, REST comes more to the forefront. In a previous blog, I discussed how Web API's should be designed around a User Model. Because we are in the age of omni-channel and multi-channel architectures, web API's are becoming more and more multipurpose. Once an API evolves into the public API realm, it becomes difficult to optimize for different clients. Even for API's behind the firewall, once an API evolves to support multiple clients, it takes a life cycle of its own. As such API providers maintain one life cycle, while consumer apps, maintain another. Once consumers have a different purpose and life cycle than API providers, client apps need to be able to evolve screens and use cases based on end users. App Store comments can bring a great speed of change to a UI, and a multipurpose Web API cannot respond to tons of clients for risk of breaking another clients. Therefore, the client applications need a place to write code to perhaps change API JSON data to UI specific JSON. They may also need to make multiple API calls to create the desired UI Model. Client applications can write client side code on a device to handle changes, however, this can cause lots of unwanted side affects. They can consume too much data, create extra network calls, and expose security characteristics. Therefore, there is a case for a piece of serverside code that is owned by API consumers. The code is meant to handle data transformation specific for their application without having to do this on the device. This is the role of a Worklight Adapter, it is a piece of serverside code that is owned by API consumers. It is not a technology for the creation of API's to a vast array of consumers. It can be a piece of logic shared by a set of consumers that is owned by the same application team, but it is specific to the consumer's life cycle. The figure below shows an example:
Having a Worklight Adapter tier has many advantages:
In a BlueMix model, you can use something like a CloudCode Service to provide this, but of course you pay for services you use using a cloud model. You can use API management technology or create specific REST Services for specific clients, but that puts the consumer mobile app team and the API provider team under shared infrastructure, dependent schedules and so forth.
Net/Net, there will be a need for serverside code owned by the consumer development team in many scenarios, and Worklight Adapters solve that issue quite nicely. I would say this tier is almost necessary in order to create the most performant and secure Mobile Apps.