Smart developers use Application Programming Interfaces (APIs) to create applications. After all, letting someone else write and maintain as much of the code for your application as possible only makes sense. However, you need to choose APIs with care to obtain the best benefits from using them without incurring most of the risks.
The days of the application created by a single pizza-eating developer lurking in a dark office in the basement of an unknown building are pretty much over. It can happen, but the chances of success get smaller every day.
A number of factors are contributing to the demise of the single developer, but the most important reasons are time and complexity. Most developers don’t have time to create an application from scratch any longer, because users want new applications, stuffed full of innovative feature, in a considerably shorter time. In addition, the development environment is more complex; applications must now run anywhere on any device.
Freely available APIs solve these two problems (and many more)! Among the obvious reasons to use an API are reducing both development and code maintenance time. In addition, you gain reliability, because the API is tested by so many applications and is constantly updated to reflect the detection of errors in the code. APIs can also prove speedier than custom code a developer writes—again, because of the thorough testing that an API receives. It’s really easy to make a good business case for using APIs to develop applications.
However, using just any API to solve your problem is the worst possible way to achieve your goals. Using the right strategy for selecting APIs is essential to guarantee success.
Defining What You Want to Achieve
Because you’re using someone else’s code, which consists of a library of predefined routines, you have to approach each API as a black box with specific inputs and outputs. No two APIs are precisely alike. An API may not exactly match your needs, but one API will almost certainly come closer to achieving that goal than any other API you review – and certainly is better than trying to design something from scratch by yourself.
So, you must ask yourself whether this particular black box produces the output you require given a specific input. In addition, consider whether the API as a whole performs all of the tasks you need to complete within the application. If not, you may need to use multiple APIs in tandem—a somewhat common practice that is accompanied by all sorts of compatibility problems.
Everything comes with a cost. When working with an API, you won’t get precisely the look and functionality you originally wanted from your application. Your application becomes standardized to the API, rather than following the course that works best for your organization or its coding style. What you get is someone’s generic approach to a given problem modified by your own customization (when such customization is available). In addition, your code must adhere to the API’s way of performing tasks, so you lose a certain level of creative freedom.
If your goal is to create a unique application or design a real-time system that requires close contact between the software and the hardware, an API isn’t the solution. Most developers who use APIs want to create business or entertainment applications where commonality of appearance or less than perfect interfaces isn’t a problem, or when you need some kind of functionality “plugged in” behind the scenes.
Developing a Management Strategy
You need to think about APIs’ differing characteristics before choosing one. These characteristics determine the best management strategy to interact with the API successfully.
For example, some APIs provide both a hosted and a downloaded version of the code, and there are pros and cons to each approach.
When you use the hosted version of the code, you gain instant access to the latest version of the API with all of the requisite fixes and updates in place. This level of automation has significant benefits, such as application performance improving without you doing anything at all (if the API developer enhanced it to do so). In addition, using the hosted version reduces your application’s overall size. All the user needs is your code and an Internet connection to access the library code on the hosted site. Hosting also tends to reduce problems with firewalls because the user doesn’t have to download the API code to use your application.
With a downloaded version, you gain application speed, reliability, and security benefits. Having the API locally means that your application isn’t constantly sending requests over the Internet where network speed and latency become factors in overall application speed. Hosted sites can also experience down time, Distributed Denial of Service (DDoS) attacks, and other issues that could make your application unreliable. In addition, when all of the code is on the local system, it’s easier to monitor and to improve overall application security so that it becomes less likely that someone will spy on your application. Finally, using a local copy of the API means that your version of the code remains consistent, so you avoid compatibility issues that can occur when moving from one version of an API to another. In fact, some applications refuse to work with a different version of an API, so versioning is an important issue to consider.
Depending on the API, you could gain access through a Web service, template code, generated code, or all sorts of other methods. Each of these methods of access has its own set of advantages and disadvantages. Don’t ever assume that you can simply use an API without a management plan in place. In a best case scenario, you’ll wake up one morning to find that the API has changed in some way and that your application won’t work. In a worst case scenario, you’ll find that your systems are down and that someone has absconded with all your data.
Considering the Security Implications
The API you choose must pass muster when it comes to security. Depending on how you use the API, you need to consider issues such as the integrity of the data the API manipulates for you. A user interface API requires less security than a database API does because the user interface API doesn’t manage the data directly; it acts only as an input that you monitor as part of your application. But in both cases you need to ensure that the API is written by someone you trust not to act with ill intent toward your organization, and that it is written by someone who is unlikely to include security vulnerabilities in the API itself. In short, there’s a trust relationship between you and the API creator that you’re responsible for checking and monitoring.
Even when you establish a trust relationship with the API creator and verify that the library works as intended, there are all sorts of security factors to contemplate. For example, think about how data is transmitted and whether a third party could potentially gain access to the data stream. It’s also important to determine what happens to the data should an error occur. In some cases, data loss is impossible to avoid, but you want to be sure that the API includes safeguards to make data loss relatively rare.
Overcoming the “Also Ran” Look
Every development team wants its application to look unique. Yes, the software should adhere to certain conventions, but the specifications used to create appearance offer wide latitude over how the look is achieved. Some APIs are cast in stone, while others allow you to make modifications or augment the API in some way. The more flexible an API, the easier it is to avoid the appearance of using an API in your application. (After all, none of us want to generate the UI equivalent of a user thinking, “Oh, I know just which jQuery or jQueryUI template they chose!”)
Flexibility makes it possible to tweak the API so it better meets your application development needs. Here’s a list of the most common techniques that API creators use:
- Overrides: In some cases, especially when working with browser-based applications, you can create overrides for the API functionality. The techniques include using CSS to modify the output appearance of library features to inheriting functionality as part of a custom class. The main drawback to this approach is that you’re piling code onto an existing API and additional layers reduce reliability, cause security issues, and reduce application speed.
- Code modification: When you download a library to your own system, you often have the option of modifying the code directly. This is especially true of browser-based applications where you have access to the JavaScript code. Of course, to make this form of flexibility work, you need to know how the API works, which counters some of the benefits of using the API to begin with.
- Generators: A lot of APIs offer direct customization through a wizard or generator. You answer questions about how you plan to use the API and the wizard or generator creates a custom version of the API for you. The main disadvantage of this approach is that you must host the API locally, which isn’t always a good option.
Bottom Line
APIs make the developer’s life a lot simpler. A developer can create an application in significantly less time and also spend less time maintaining it. Teams of developers help produce, update, and maintain the API and the API code is tested by hundreds (or even thousands) of applications. Eventually, all this testing leads to an API that’s reliable and pretty much bug free.
To gain these benefits, you must be willing to trust the API creator, which means researching the API before you use it. It’s also important to realize that your application won’t appear precisely as you intended and that you give up some creative freedom in order to use the API.
Have anything to add to this API discussion? Please leave us a comment!
See also:
