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.