[Architecture Blog] A Pragmatic Approach to the API Façade Pattern
By Asanka Abeysinghe
- 8 Oct, 2015
Façades hide the complexity of internal implementations and provide simple interfaces. This is a common pattern in computer science but we can find it in the real world too. Lets look at a real world example first: if you walk into a shoe store you find samples displayed in a manner making them easy to pick and select, but if you walk to the back of the store you will find a massive warehouse with millions of shoes that will not provide an easy way find the correct shoe for you. What does the showroom do? It provides a façade that displays the shoes in a way that helps buyers select and buy the shoes they want, thereby reducing the complexity and enhancing the buying experience.
Similarly, façades used in computer systems hide complexity and provide a better experience for the consumers (demand).
Lets look at how façade patterns apply to API Management. There is a clear gap between the consumer demand for APIs and the internal services available in each enterprise. As an example, consumers look for Web APIs that can be accessed using REST principles, deliver content using JSON and be secured by OAuth addition so that the APIs can be externally accessible and discovered. This may map to an authenticated XML/SOAP based service within the enterprise.
API façade patterns mainly contain four functional layers:
- Backend services
- External format / Demand
Most commercial API management solutions treat the mediation, façade and demand as a single functional, architecture and deployment layer.
If we look at the gap between backend services and the demand, can a lightweight mediation layer with limited service bindings such as HTTP/s, JMS build a business API? Are you willing to add the resulting additional wrapper service layer to maintain it?
WSO2 recommends a more pragmatic approach by recommending dividing the façade layer and mediation layer into clear functional, architecture and deployment layers.
This architecture can facilitate heavy mediation including service chaining/orchestration to provide a business friendly API for the consumers. This also allows one to do a clean deployment by inheriting the infrastructure policies appropriate for each layer, as well as scale each architecture layer separately.
Implementation of the WSO2 API Façade is facilitated by using the WSO2 API Manager to build the demand and façade layers and the WSO2 ESB to build the mediation layer (also add in products like the WSO2 Business Process Server if required) and connect to the existing services. If you are planning to write new set of backend services using standards such as JAX-WS, JAX-RS you can use the WSO2 Application Server as a runtime. In addition to that if there are any other business or technical requirements to build new business APIs you can add them with or after the mediation layer by leveraging the 17+ products in the WSO2 Middleware Platform.
This pragmatic and architecturally rich approach of WSO2 API Façade pattern results in many benefits for the API management solutions:
- Clean architecture by separating the concerns
- Have a clear separation of internal and external processing of an API call
- Ability to scale based on the actual usage of each layer
- Avoid implementing new services or building wrapper service layers
- Leverage SOA principles with the new Web API architecture
- Utilize the middleware and go to market quickly
Having said that if you are planning to have a single layer to facilitate all three layers of API façade, there are no technical limitations in WSO2 API Management Platform to doing that. You can build the mediation by configuring the pre-configured ESB running as the internal dispatching engine of the API gateway. However for a real-world deployment we recommend that you consider using the flexible, componentized nature of the WSO2 platform to build a clean, scalable, manageable WSO2 API Façade.