SOAP WebServices and API Aggregation in 3Scale API Management

One of the common requirements of any API Management implementation is to group backend services into one API and expose them as a single business capability with single SLA (Contract) and single authentication method, another key requirement is the support of SOAP WebServices exposure in addition to Rest Services.

In this Post will discuss both requirements and how both are provided as core capabilities in Red Hat 3Scale API Management.

API Products

Along with current release of Red Hat 3Scale API Management 2.7, The API Product concept was introduced, API Product is a new way to manage your APIs with the following advantages:

• Separate internal APIs, Backends, from customer-facing APIs, Products.
• Expose any number of Backends as one Product.
• Re-use any Backend in any Product with different service-level agreements.
• Simplify customer access to multiple Backends, by using a single set of credentials.

The API community badly wanted the API Product concept to be introduced in 3Scale, Why?

One of the challenges 3Scale users faced before is the ability to create one authentication methods - API Key for example - per API developer (API consumer) no matter how many APIs this API developer will be granted access to, as till release 2.6 users had to expose backend APIs using different 3Scale services and then create different applications (API Keys) even though all of them will belong to one developer account!

Look at below diagram:

The motive behind API Product concept in 3Scale was not only overcoming the above challenge but also fulfilling some other values including: 

• Clearly separate the Business aspects of an API (Plans, User limits, Costs, etc) from Technical aspects (private URLs, mapping rules, etc)
• A common requirement for granting same person two different “roles” even when accessing the same endpoint but in two different business scenarios (contexts)
• Make the “API Facade” pattern that creates one externally facing “clean” API from multiple “backends” a first class UI citizen (Constructing external facing API Product  from multiple API Backends)
• Reusing backends once they defined in many API Products

How does it work?

1. Create backends, each backend maps to “Private Base URL”
2. Define methods, metrics, and mapping rules for each backend
3. Create API Product
4. Add Backends to API product (all methods, metrics, and mapping rules will be inherited)
5. Create an application plan (rate limiting and cost)
6. Create application (including the API Key) to access the API Product

From Business and Technical perspective this how we distinguish between Backend and API Product

Support for SOAP Services 

3Scale provides SOAP policy that allows users to map the backend SOAP Webservices and expose them through the API Gateway, Combined with the API product concept I prepared a quick demo to show the following:

• Create two backends, one Rest and one SOAP

1. Map rest endpoints, add methods/metrics
2. Map SOAP Operations, add methods/metrics

• Combine both backends in one product 

1. Add first backend under path ‘/rest”
2. Add second backend under path ‘/soap”

• From API Product Gateway settings, select “API Key” Authentication method
• Add SOAP Policy to the API Gateway and map the SOAP Operations to handle the SOAP backend service
• Create Application plan

1. Define limiting rules at backend level
2. Define pricing rules at backend level

• Create application with valid API Key
• Test all Rest endpoints and SOAP services through using one API Key and one Gateway URL

Below is the Demo high level diagram:

In this demo we will expose following service 

reqres rest: public URL exposing Rest services (visit https://reqres.in:443 for more details)

crcind SOAP: public URL exposing SOAP services (visit https://www.crcind.com/csp/samples/SOAP.Demo.cls for more details)

Enjoy the Demo

Summary

API products (aggregating backend services), in addition to consuming SOAP WebServices are core features of Red Hat 3Scale API Management, combining both together leads to a very strong foundation for any successful API Management implementation program.