This guest post comes from Mark O’Neill. Mark is a frequent speaker and blogger on APIs and security, and is CTO at Vordel. Vordel, recently acquired by Axway, provides an API Server that enables enterprises to connect to Cloud and Mobile.
Web APIs are now widely used for integration, especially to enable mobile applications. APIs divide broadly into two categories: Open APIs and Enterprise APIs. “Open APIs” are APIs which are available to any client, often hosted in the Cloud. “Enterprise APIs” run inside the enterprise and are not publicly available. So, how do Open APIs differ from Enterprise APIs? Let’s begin to answer this question by turning it on its head – what do Open APIs and Enterprise APIs have in common?
Organizations typically deploy APIs to enable mobile apps. This includes enabling Apps for employees and enabling Apps for the outside world for use by customers or consumers. In this way, Open and Enterprise APIs are used for similar purposes. Additionally, both Enterprise and Open APIs remove the requirement to deal directly with legacy systems, and use simple HTTP interfaces instead. This allows organizations to interact with an API rather than connecting directly to a database or a message queue. Therefore, both Open and Enterprise APIs offer a more easily usable interface in front of existing legacy enterprise systems.
So, now that we know what Enterprise APIs and Open APIs have in common, let’s see how they differ. Typically an Enterprise API is used within an existing closed system, where users (often employees) are already known, in a directory or database. As such, an organization using an Enterprise API will know who the user is. With an Open API, an organization wants to achieve the maximum reach. For example, it wants anyone to be able to write Apps or call its API. Therefore, Open APIs usually incorporate a “self-service” aspect, where users can self-register. This is a key difference between Enterprise and Open APIs.
With Enterprise APIs there is usually a greater emphasis placed on controlling identity and security. As a result, organizations using Enterprise APIs will want to leverage their existing identity stores. For example, they will want to leverage employee directories, as well as leveraging how their employees already sign into systems to ensure they can also sign into APIs.
Consider an example of how APIs are used in a large mutual fund company where employees manage pension funds and similar products. In this scenario, Enterprise APIs enable money managers to perform trades and to access fund prices via mobile Apps. This is important for the firm as its employees need to be able to do their job from anywhere, be it on an iPad in a coffee shop or on a laptop at their desk. However, while the employee is working remotely, it is critical to guard access to private data. This is an important aspect and it is where the link to the corporate directory comes into play. This approach requires single sign-on between different Enterprise systems combined with identity management.
For Open APIs there are still requirements for security. The security requirement does now go away. However, when it comes to questions of identity, there is more focus on allowing people to sign up easily – self-service. For example, if an organization deploys an Open API it typically wants to make it as easy as possible for Developers to use the API. In this instance, an organization wants Developers be able to self -register and get up and running with its API so they can build Apps as quickly as possible. As a result Open APIs have more of a self-service ethos with a Developer portal enabling Developers to use the APIs, develop Apps and set their passwords — all via the Developer portal. This approach is different from an Enterprise API where the organization is aware of the identities of its users and its Developers in advance.
With Open APIs, organizations are often providing feeds of data that anyone in the world could access. For example, a utility company may be providing information about the pricing of utilities or a transport company may be providing information on locations of trains and buses and so on. This information is public information. However, the process requires management to ensure it is not being abused by clients who could monopolize the traffic or perform a denial of service or use this service to the detriment of other users. A solution to govern the flow of traffic involves quota management and restricts client traffic. For example, it would permit only a certain amount of messages per second, per minute or per day. This approach is typically used for Open APIs.
With an Enterprise API, typically information is not being provided to the entire world. The security is basically ensuring the people connecting to the API are who they say they are. This approach requires authentication of public lives — which is different from the Open API approach.
Due to the breadth of different types of Client Apps, Open APIs have a requirement to support REST, as well as supporting SOAP. This is due to a need to support different mobile platforms and provide Clients with sample code for calling the API from an iPhone App, from an Android App or a Windows phone. Thus Open APIs have to support REST and have to provide sample code for various different platforms.
With Open APIs the focus is on making it as easy as possible to use APIs, so providing enablement services for Developers is important. For an Enterprise API, the Developers may already be skilled in using the APIs. In fact, they may have developed the API and would be very familiar with it. Whereas with Open APIs, it is critical to provide all that information to Developers to ensure they are able to build Apps immediately.
Going forward, organizations will continue to need both Open and Enterprise APIs. They will leverage Enterprise APIs for enabling their mobile workforce and will use Open APIs for enabling the world at large. To maximize efficiencies, protect security, and drive business the organization will need to manage all of this with a single platform that supports both Open and Enterprise APIs. This single platform approach will allow an organization to avoid using one platform for Open APIs and another platform for Enterprise APIs — which is a time consuming, risky and expensive approach. A single API Server platform, supporting Enterprise and Open APIs, is the answer.
As the enterprise edge extends to both Open APIs and Enterprise APIs, it is clear that APIs have become a way to connect to the outside world rather than a way to keep it out. To get the most out of APIs, I recommend you think of APIs as similar to a Lego block sitting within your enterprise edge which can be used both for enabling external users and also enabling employees.