The often ignored question regarding API construction is, "What technology should be used to build an API?" Typically,...
the decision about language or hosting is barely an afterthought. For an application written in C#, the API will most likely be written in C# and hosted on an Internet Information Server. A Java-based app will probably have its SOAP or REST API written in Java and hosted on whichever J2EE container is available.
For any application whose language supports it, a Web-based API is typically constructed on the same stack as the application itself. That seems like common sense on the surface. An API team and an app team might be one and the same after all. Besides sharing skills and knowledge, one might be tempted to share infrastructure between application users and API clients. Is this the best course of action?
There are multiple reasons, including stability, security and quality, that make a strong case for choosing a different development language for public API construction. Here are a few areas to consider.
An application's internal hosting environment is tuned to existing internal users. Whether that environment is given double-duty to support external clients or duplicated in its entirety, it wasn't designed for the different level of use that an API demands. Best case? An API that performs slowly. Worst case? Existing users are impacted.
An application and its API must be intertwined from a contractual standpoint. The API can only expose features that are ultimately supported by the underlying system. When both the API and the application are written in the same language, the possibility that there will be drift between the API and application increases.
It's an easy trap to fall into. A developer makes an enhancement or fix to some code that is also used by an existing API method. The developer tests the front end -- but not the API -- to confirm the change was successful. Just because the front-end test cases succeed, doesn't mean the API hasn't been affected. The application change might expose undesired information externally, or impact API performance. A separate team responsible for API construction and testing should be able to identify and prevent API drift as part of its regular development cycle.
In years past, a few platforms have shown themselves to be more vulnerable to either falling over under load or open to malicious attack. If running one of these platforms internally, this might not be something to worry about. But as soon as they're operating on the other side of the firewall, there is reason for concern.
Keep in mind that good design means understanding audience. When the primary application and API are developed by the same team on the same platform, there is a tendency for the API to closely mirror the structure of the application. This is usually very far off from what external developers are looking for.
They don't have (or want) familiarity with how an application is written in order to chain a series of API calls together to accomplish a specific goal. They are different class of customer, and their needs require special consideration. Constructing APIs on a different platform will create a hard distinction between the current product and its API. Otherwise, there's risk of just API-enabling what's already there. A dual-team structure facilitates refining an API in private, internal conversations rather than in a public forum.
There are, of course, other reasons why hosting an API on an alternative platform makes sense. There may be no choice when API-enabling a legacy technology, for example. It's possible to find cheaper talent and better performance from alternative languages. Furthermore, commodity infrastructure or more favorable license agreements may be used.
Some larger companies already have skills and assets across multiple platforms, so the decision to construct an API in a different language is not so far-fetched. A smaller firm might balk at the notion of hiring and training new staff and building out new infrastructure. Discussing alternative languages costs nothing, but it might just help spot the weaknesses in an approach if the decision is made to develop and deploy on a common platform.
About the author:
Michael Ogrinz (@mogrinz) is the author of Mashup Patterns: Designs and Examples for the Modern Enterprise. He is also principal architect for global markets at one of the world's largest financial institutions.
Effective API development
High-level and low-level API
API best practices and advice