ManageLearn to apply best practices and optimize your operations.
Why different languages should be used for app and API construction
From stability to security, there are several reasons why different development languages should be used for application development and API construction.
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Step 2 of 2:
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.
Hosting
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.
Security
An application and its API must be intertwined from a contractual standpoint.
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.
Stability
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.
Quality
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.
