What Makes an Agile API?

Agile. API. API. Agile. It has a nice ring to it, but what exactly makes an API agile? Christian Nilsson of Beepsend SMS messaging solutions looks to rock the idea of what it means to be truly agile. Having become a buzzword, ‘agile’ often comes loaded with misconceptions. Nillson offers 7 tips to help an API provider determine what it means to have an agile API.

To start off, let’s break down the two components of the “agile API”:

What is Agile?

While agile is an openly used term, Nilsson defines it as an approach to problems, a software development process, and a business process. Like it’s name literally suggests, an agile business is lean, nimble, and filled with passion, but able to react to change rapidly.

To Nilsson, agile has three common themes:

Agile is breaking things down—but not to the point that they break.
Agile means you can quickly shift business strategy.
Agile cannot be burdened by previous decisions.

What is an API?

The textbook definition of an application programming interface (API) is a set of protocols, routines, and tools for business software applications. According to Nilsson, the possibilities of APIs for businesses are more intriguing:

An API enables other organizations to make you bigger than you could be just by yourself.
An API can make you relevant in more areas than you could have imagined.
An API can redefine your service.

The Seven Misconceptions of the Agile API

It’s clear that agile is a hot term used to describe many business processes these days. And naturally, API providers are trying to incorporate agility into their own services and business processes. However, the idea of an agile API has some misconceptions floating around. We’ll go through the main ones below.

Agile API Misconception #1: You Need to Build and Maintain It All by Yourself.

Don’t be a MacGyver. Services should focus on what they do best and then allow others to do the rest. Partner with other APIs that do things better than you—you strengthen their core product while not losing sight of your own, and both organizations will increase traffic. These partnerships can be created directly or indirectly through an integration service like IFTTT or Zapier. This keeps you focused on building a reliable system instead of risking fragmenting what you do best in a misguided effort to tailor to one or more clients’ particular needs.

Agile API Misconception #2: If You’re Not Agile, You’re Not Successful.

In general, the closer a service is to the end consumer, the more agile it needs to be in responding to problems. As Nilsson says, “Internet users are fickle and promiscuous. They’re curious. They’ll leave your service in a heartbeat.”

However, some businesses are naturally inflexible. When these businesses increase their distance from the end consumer, they become less agile and more stable. This gives the business a stronger reputation for reliability, which is a highly marketable trait to less flexible industries like banking.

Services should ask themselves: Why do we need this API? What does ‘agile’ mean to us and our business model? Is it right for us? Is it right for our customers? In the end, success doesn’t come from agility alone. Success comes from passion for the core business model.

Agile API Misconception #3: There is Only One Perfect Software Development Process.

So often, project management tools are thrown at software developers in order to make them work faster in a more transparent environment. But software development processes vary by needs, and corresponding tools should support — not enforce — a set of processes.

Project managers for APIs should start by assessing the size and makeup of their development team, along with critically analyzing the problem the team is trying to solve together. Considering these factors, the right strategies for development will naturally arise, often straight from group discussion on the topic.

Agile API Misconception #4: Your System Is Secure.

Security doesn’t start and end with outsmarting hackers. Nowadays, no matter how secure your system is, you are constantly battling against an infinite number of scripts, human errors and stealthy passwords. In this constantly unstable and insecure world, one shouldn’t relax and assume that all is peachy.

One way to overcome this seemingly insurmountable obstacle is through central configurations, which make sure that keeping your systems up to date is not labor intensive. You must be vigilant for any holes in the technology and to make sure that all developers are taking active steps to avoid cross-site scripting, or XSS flaws.

For an in-depth study on API security check out: API Security: Deep Dive into OAuth and OpenID Connect

Agile API Misconception #5: Your Extensive SLA and EULA Will Save You.

The reality of a Service Level Agreement (SLA) or End-User License Agreement (EULA) is that it is a best-case scenario. Nobody wants downtime and for things to break, do they? But how often will your team or the customer have the money and patience to bring a side to court on the matter? You may like that your SLA or a EULA creates a sense of fear, but Nilsson argues API providers should be trying to invite people instead of scaring them away with lengthy user agreements.

Agile API Misconception #6: Your API is ‘Special.’ Keep That Secret Sauce a Secret.

According to Nilsson, there are no secrets in coding anymore. The “secret sauce” of a business lies within it’s execution, and within the team. The secret sauce is how you can adapt and transform to fluctuating markets. It’s how you practice agility. And it’s also how you provide fantastic customer service.

Technology is just one more conduit from which you can support your employees and help them strive for greatness. Plus, if you keep your tech a secret, when things go wrong, who will you be able to lean on? Communities established around open code and collaboration can help APIs dramatically increase in value; that’s what smart cities all over the world are realizing by opening up their data silos and API source code.

Agile API Misconception #7: NoSQL is the Future That Will Power All APIs.

Nilsson argues that the NoSQL database for storing and retrieving data just isn’t all it’s hyped up to be. He concedes that NoSQL has the ability to solve many problems, but not all of them. Like with all things in the programming and development world, solutions need to be agile. You need to look at each problem and pair it with the best solution. Often times this means pairing NoSQL in combination with other solutions like a relational database.

Conclusion

In the end, API providers must incorporate creative combined solutions for development that are tailored to their unique position. When building an agile API, you must keep all these facets in mind without falling victim to misconceptions of what it means to be agile. Following these considerations, you should be prepared to react properly to your team’s needs, your business’s needs, and the end consumer’s needs.

What makes an API truly agile? Feel free to share any insights your team have gained from using agile API development processes below. And as always, thanks for reading!