The commoditization of technology has reached its pinnacle with the advent of the recent paradigm of Cloud Computing. Infosys Cloud Computing blog is a platform to exchange thoughts, ideas and opinions with Infosys experts on Cloud Computing

« October 2013 | Main | August 2015 »

February 27, 2014

Is your service ready to be 'API'-fied? (Part 2)

In my previous blog, we looked at the data and security aspects that might hinder an internal service from being API-fied. In this conclusive part, we will look at the other two important aspects that needs to be addressed before internal services can be certified for API exposure.

 

Scalability is the next key area to talk about. Exposing APIs for external consumption can quickly lead to explosive growth in traffic due to genuine or rogue usage. Will the back-end applications, databases and infrastructure be able to scale as traffic swells? APIs exposed to external consumption usually have stricter service level agreements and financial implications to adhere to.  But that should not come at the expense of the internal consumers. Imposing usage quotas and throttling limits is just one way of managing growth in API traffic. A complete discussion on API scalability however merits a dedicated blog.

Last, but not the least, is service design. Service granularity is a tricky subject and in many cases consumers of internal services have to make several calls to the back-end to complete a transaction or achieve a functionality. While this might not be a big challenge for internal consumption, when it comes to externalizing these APIs, it makes the consuming apps unnecessarily "chatty".

Internal services are also often infested by the 'pass-me-back' syndrome i.e. sending pieces of data absolutely irrelevant to the consumer but required to be passed back by the consumer for future calls. The problem creeps in during early service design for the ease of processing and lives through internal consumption without much fuss. However, when the same services are exposed for external consumption, these design issues may be barriers to API adoption.

API Management products that are available in the market provide a lot of capabilities especially in the area of security and traffic management. But as you can see from this blog series, it takes a lot more than just a product to make an API strategy successful. There's no one-size-fits-all solution.


February 12, 2014

Is your service ready to be 'API'-fied? (Part 1)

A question that I come across pretty often, especially with clients who are pretty early in their API journey, is "Can I expose my internal service as an API?"  The answer unfortunately is not a simple Yes or a No. Even though APIs are supposed to build over SOA, something that the industry has been doing for quite a while now and many have mastered, there are several considerations that should be looked into before an 'internal' service can be 'API'-fied (A new word I just coined J - meaning "exposed as an API"). In this 2 part series, we take a brief look at these aspects which are key to answering that question.

To begin with, examine the data being exposed through the service. Since internal services are meant to be consumed within the organization, data security and governance in most cases are relaxed. However, when it comes to exposing the service to external entities, the equations change.  It is therefore important to carefully review the service and ascertain the type and sensitivity of the data being exposed and make sure that you are ready to expose it to the external world.

Security is the next key aspect that must be delved into. Internal services mostly have none or not enough security built into it for external consumption. Even those that do have might have a proprietary security mechanism back from their early SOA days.  All these are dampers for APIs. The API economy is meant to be open. Hence it is important both to have a robust security architecture and one that conforms to commonly accepted industry standards (e.g. OAuth). It is also important to abstract security out of the service. Security should be managed by experts through policies. That will free the service developers to focus only on the business logic.

In the next part, we will look at how scalability and service design play a key role in answering the question.