API Facade Pattern: Technology for orchestration, transformation, compression, authorization
In the previous post about technologies to implement an API facade, we covered technologies for handling versioning and caching scenarios as well as firewalls. This time we'll summarize the technologies to handle other common use cases.
Another common pattern we see is the insertion of a facade to orchestrate across a complex and fine-grained set of API calls. The design represented by the anti-pattern diagram below will likely present a poor and complex design to the app developer.
The facade in this scenario orchestrates across a number of calls. There are configuration or policy orientated orchestration technologies available or you can write the orchestration logic in code. Code is often one of the best orchestration tools but the approach you take will depend on the skills and capacity of the team that's implementing the API facade.
Transformation & Compression
To handle the common use case for apps, in general, of transforming XML to JSON or vice versa, you would use a transformation library (like XSLT) in the facade.
To handle a common use case for verbose and large XML documents, you add a compression engine to your API facade. Not clogging the bandwidth is especially important for mobile apps where large payloads become a problem because they impact the cost of users' data plans and use battery powering the radio. Apps that impact the users' bottom line get uninstalled.
Finally, let's look at how to handle authorization through the API facade. A request comes into the facade with an OAuth token or other indications of the authorization scheme. The facade can make the calls to the authorization system of record.
If the request is valid, the facade passes it to the core system; if invalid, the facade returns with an invalid response code.
Next - we'll take a look at the people considerations for implementing an API Facade.