Lightweight and Scalable Integration Style for web based collaboration

Since the overall collaboration in web based API model is driven by opportunities and needs shorter time to market, a lightweight, scalable and affordable integration style is required which can enable Organizations to quickly participate in overall API value chain.

Due to its simple, lightweight, low cost and scalability aspects, REST (Representational state transfer) is best suited to enable quick web based collaboration. The web APIs that adhere to the principles of REST architecture are known as RESTful APIs. The use of REST architectural style and RESTful APIs have been dominant among companies operating in social networking and other web application space for building scalable integrations. The benefits of this standard and low cost integration style are already proven by these companies.

Now this proven RESTful API model is being gradually adopted by mainstream Business segments like Banks, Telecom Operators, Retailers and Manufacturing companies for building digital platform.

Access to functionalities and data buried within Enterprise applications on real-time basis is absolute necessity today, whether it is needed by internal applications-channels or external partners or third parties. SOA has partially fulfilled this promise by building loosely coupled SOAP based shared services model for internal consumers. ROA (Resource-Oriented Architecture – REST architectural style) fulfils this promise further by making Organization’s capabilities accessible to web based external consumers and Organization’s own digital channels. External consumers can leverage RESTful APIs for quickly delivering collaborative offering or value added service.

REST/JSON and SOAP are always compared on wrong grounds and debated to decide which one is better without understanding the synergy between these 2 styles. They have their own significance and role to play in the Enterprise. SOAP (used in SOA) is primarily used in middleware domain for exchanging well structured data between Enterprise applications. REST/JSON is used primarily in Web domain for integrating web based applications.

Why not SOAP for web API model?

Web API model has different requirements altogether given the fact that APIs are targeted for effective collaboration and quicker time to market. Some of the key expectations on integration style are –

  • Lightweight
  • Simple Design
  • Scalable
  • Adaptable
  • Low cost and affordable
  • Faster Development
  • Standard and Supportable

SOAP does not meet most of the above requirements due to following reasons –

  • SOAP is complex and heavy as compared to data formats used in REST architecture.
  • Developer communities need to have good and detailed understanding of SOAP protocol for implementation which makes it time consuming affair, thus longer time to market.
  • In most of the scenarios features provided by SOAP protocol and the underlying WS-* standards are not required for web based collaboration.

Having said that, there might be few use cases where SOAP is preferred.

REST/JSON being lightweight, enables quick collaboration with partners and third parties with minimal development effort and complexity.

REST Quick Overview

REST is a web architectural style, more precisely a client-server web architectural pattern based on Resource-Orientation paradigm. In the context of API model, client is API Consumer and sever is API Provider.

Below are the key concepts around REST based integration style

  • Resources
  • Actions
  • Data Interchange

Resources: ‘Resource’ is at the core of REST based architecture. As such resource could be anything – image, video, file, information and so on. For mainstream Businesses, (operating in domains such as Banking, Insurance, Telecom, Retail, Manufacturing) core business functionalities and data takes the form of resources to be exposed to app developer communities (internal, partners and third parties) through the notion of APIs. For example, product related functionalities-data can be bundled under products resource.

Resource could be collection of homogeneous objects (For example, products collection representing all products) or a specific object (For example, products/2345 representing a particular product with id – ‘2345’)

Actions: REST architecture does not define any specific actions. REST relies on underlying HTTP protocol for this purpose, it leverages the HTTP methods/verbs like GET, POST, PUT, DELETE to specify actions on a resource.

Data Interchange:
The most widely used data formats for representing a resource in REST architecture are JSON object (JavaScript Object Notation) and XML. However, JSON is more popular than XML. JSON is based on simple universal data structure and due to its lightweight nature, JSON is easier and faster to parse giving better performance than XML.

Let’s look at the SOAP and JSON sample Product Catalogue response messages to understand lightweight nature of JSON.

SOAP Response over Http:

SOAP Response Example - JPEG

click on image to enlarge

JSON representation of a Resource over Http:

REST Response Example - JPEG

click on image to enlarge

So to summarize, SOA-SOAP largely remains an Enterprise architectural stream focusing on reusability within Organization; REST architecture and RESTful APIs have emerged as a mainstream mechanism for making Organization’s capabilities-services accessible to the external world in a lightweight and scalable manner.

Familiarity with Http verbs, status codes, JavaScript makes the overall REST based implementation-collaboration very easy for web application developer communities, improving time to market.


On a separate note, it is also important to understand why REST/JSON may not be the right integration style for application-to-application integration scenarios within Enterprise.

Why not REST/JSON for application-to-application integration?

Though in some cases REST based architecture is promoted for integrating internal Enterprise applications, in most of the cases it may not be suitable because application-to-application integration will have its own set of requirements which cannot be addressed by REST style. For example, below are some of the common requirements-considerations which go in favor of using SOAP as a mechanism for exchanging data between internal applications.

  • Reliable and Guaranteed delivery of data
  • More structured information exchange between applications
  • Canonical model and messages

Messaging transport is very commonly used for integrating application as it offers reliable and guaranteed delivery of Business critical data/events; additionally, messaging offers better scalability. SOAP in itself is a protocol and it is transport agnostic, SOAP messages can travel over JMS as well as Http, thus making it the most suitable integration style for internal application integration. REST is tightly coupled with Http protocol and relies on its features, there is no messaging transport in REST model. Another requirement could be to expose semantically well-defined information about customer as Data Service across multiple consumer channels like CRM, Branch applications etc. Exchanging structured customer profile information embedded in SOAP envelop to consuming application over preferred protocol JMS or Http is very common scenario. These are common aspects in Enterprise integration scenarios and makes SOAP an ideal fit.


Please refer to ‘Publication Schedule’ page for upcoming articles.

Please note that the articles in this portal discusses API examples from the perspective of mainstream business segments like Telecom, Banking, Retail, Manufacturing etc.

Leave a Reply