Inter-connectivity is the magic word nowadays as we need to leverage each other services to orchestra a seamless and cohesive UI experience for our users. API services are now very popular as they are the “contract” or “entry points” which empower orderly collaboration of services. API services encapsulate the service and provide a public interface which can integrate other services behind the scene. APIs are usually implemented as Restful interface which in turns can access other Restful or non-Restful services. A simple design pattern below will federate the API services and provide an unified public front-ends. In order to illustrate this example, I’m using Amazon Web Service (AWS) API Gateway and Lambda Functions to create this multi-layer architecture.
Here is the logical flow for this API example:
We will have 2 Lambda functions and 1 HTTP service available from different back-end system. We will create API in the AWS API gateway to access those services, using Get and Post methods. We will also secure some of the service to a particular group of user and user will need to provide their credential in order to access.
This architecture design is not exclusive to AWS, you can use many other cloud base solution as well as build them yourself if you already have the infrastructure available. The general concept of an API Gateway that can reach into other available services and enforce access security is the design pattern in this article.
So just like a recipe, what are the needed ingredients?
- You need to have the back-end services that you would like to link your API to.
- You need a publicly available access point, in AWS, it is called an API Gateway.
- Although it is a publicly available access point, you should still have option to secure it by authorizing specific user to execute specific APIs.
- The API should be implemented as Restful, which will provide better compatibility and flexibility for your clients.
- You must define your API and have it linked to the back-end services from #1. For example, it maybe the ability to trace the activity for a delivery tracking number, maybe it is to retrieve a particular set of products from an online store, or maybe even to post an order to an online store.
- There may also be additional security needed between the API layer to the back-end layer to ensure secured access. Keep in mind in this case, there maybe 2 set of identify, the identify of the API layer, and the identity of the actual end user.
Lambda Functions:
I’ve created 2 Lambda Functions in AWS:
- GetHelloWord : will simply return “Hello from Lambda”. This is the good old hello world example you would see in any programming exmaple.
- GetHelloWithName: will accept one user provided name parameter, and will return “Hello <user provided name>” back as a result.
This is a very simple implementation, the idea is to illustrate the connectivity and accessibility of the APIs. You can easily extend this example so that the Lambda function actually do much more complex things like accessible databases and invoking other Lambda functions.
The Lambda functions are created with Node.js 6.10 runtime:
Here are the code for the Lambda Functions:
//GetHelloWorld
exports.handler = (event, context, callback) => {
callback(null, 'Hello from Lambda');
};
//GetHelloWithName
'use strict';
console.log('Loading function');
exports.handler = function(event, context, callback) {
var name = (event.name === undefined ? 'No-Name' : event.name);
console.log('"Hello":"' + name + '"');
callback(null, {"Hello":name}); // SUCCESS with message
};
Restful HTTP Get Request:
I also leverage an example HTTP service available in the AWS demo environment, that will return some information from a Pet store database.
Using the AWS console, I’ve defined a new API called “myApi”:
- As you can see we have a GET and POST for helloworld and a GET method for the pets store service.
- Please note that all APIs are protected with AWS_IAM which allow access to only users that below to a particular user group with the correct security policy.
Once these are all configured, I can test them in the AWS console, and then I can deploy them to a stage in AWS, where I can access the API remotely. As the APIs are secured and need user to authenticate, you will need to use some type of client that can provide the user credential. When a user is created in AWS, an AccessKey and a SecretKey is provided to the user. The client can use the information to create an authentication token for the API call.
In this example, I used Postman to connect to the API services. Postman is a very useful and flexible to work and test with APIs. You just need to select the options, and provide the necessary inputs. In addition, you can view headers, cookies, and the actual code so that you can do some debugging if need:
Conclusion:
After an hour or two configuring and coding in AWS console. This basic API pattern is now live in AWS. One thing to highlight here is that once you have your architecture setup, creating new APIs to connect to existing back-end services specially some of the legacy services will become much more streamlined and secured.