11436 SSO

API Facade Design Pattern: Technology for set up

Brian Mulloy
Apr 06, 2012

In previous posts in our series about the API facade pattern, we looked at the basic steps to implement an API facade as well as at common patterns.

This time, we'll start exploring the technologies at the heart of implementing an API facade. We'll begin with the set up involving DNS, Cloud Platform, Web server, app server, API Gateway and subdomain routing.

DNS Provider, Cloud Platform

In the spirit of test-driven development, the first thing to set up is our test environment. The first piece of technology we'll need is a DNS Provider.

Set up a CNAME entry, which points to our test facade. A good choice for the subdomain is api-test.

For the sake of our example, we're assuming a Cloud Platform technology because it's the most complicated case and will allow us to explore the most options. It's definitely simpler if everything is behind your firewall.

Web server, app server, API Gateway

Once you have the DNS and the Cloud Platform set up, you are ready to implement the first patterns, errors and data stubs.

To ensure that you have a solid foundation for test-driven development, HTTP codes and error responses need to be in place; you need to be able to stub out data to support mock=true and raise={HTTP code}, and so on. To do so, you need either a static Web server, or an app server for more dynamic content, or an API Gateway (the Swiss army knife for this scenario) in the Cloud Platform.

Subdomain routing and production environment

The next step is to set up your production environment. You'll add a new CNAME entry in the DNS so that the poduction subdomain is api. In our example below, we've pointed api to the same Cloud Platform as in our test environment, but of course you can have different test and production targets if you like.

In the API facade, you'll specify the IP address of the target system.

Note that the error capability is also here in the production environment. Just as it is important in the test environment, you need to ensure verbose error messages and comprehensive codes in the production environment.

With these pieces in place, you'll have requests coming in to api-test and api. In addition to the target IP address, the facade has a shunt that knows where the subdomain is and understands where to point - for example to the data stub server for test or to an internal system for production.

Next time we'll look at the technologies that support versioning and URL routing, firewalls, caching, and more.

Scaling Microservices