What is an API, and Why Use One?

What is an API?

API is an acronym for application programming interface, and it’s usually defined as something like “a set of routines, protocols, and tools for building software applications.”

The term often gets used in technical circles, but even there, most people, unless they are software engineers and developers, only have a vague idea of what an API really is.  

Most large companies and products that you use on a daily basis - Facebook, Twitter, Gmail, Google Maps - have all built APIs for their customers, and for internal use.

So what is an API?  Essentially, an API is just a structured format and interface for data to pass back and forth.  The weather app on your phone uses an API to pass your location, in a specific format, to a weather service, and gets back the prediction for the weather for the day, in another specific format, probably a JSON file.  

The app on your phone then interprets this, and displays it in a nice fashion using a graphical interface, but that’s built on top of the information provided by the API.

In a web-based context, an API is like a webpage for a machine.  It serves to connect programs on both sides.

Image source: http://www.seamgen.com/blog/why-apis-are-important-for-business/

Image source: http://www.seamgen.com/blog/why-apis-are-important-for-business/

Essentially, an API is a layer that provides a standard, usually easier, way to communicate information.  You can think of the steering wheel in your car as a type of API - you don’t actually know how the software works in the car, but you know how to input directions to steer left and right.  The car is built to transmit that information to the wheels, and will provide feedback in the form of resistance to your hands.

Google Maps API lets developers embed Google Maps on web pages, and have those maps be dynamic, communicating with the information underneath Google Maps, and adjusting to user input.

The following graphic, as an example, shows all the built-in API tools for Microsoft Visual Studio:

Image source: https://blogs.msdn.microsoft.com/visualstudio/2015/03/24/introducing-the-azure-api-apps-tools-for-visual-studio-2013/

Image source: https://blogs.msdn.microsoft.com/visualstudio/2015/03/24/introducing-the-azure-api-apps-tools-for-visual-studio-2013/

Why Only Use an API?

Here at Lean Systems, all our products are API-based, instead of providing a graphical user interface.  That’s not to say we don’t have any graphic interface at all - we’ve built spreadsheets and basic dashboards to communicate with our API for various clients - but in general, we try to keep focused on providing only the API.

There are a few reasons why we believe considering only an API is a good idea (which are why we made that choice too):

  1. Flexibility for our customers

  2. Focus for company and team

  3. Flexibility in the products you build and test

Let’s talk about each in a little more detail.

Flexibility for Customers

For us, when we thought about our customers and the use cases for our technology, one thing became clear - most of the applications for our technology are mission-critical - they really can’t fail.

Whether it’s crew scheduling, routing of vehicles, maintenance planning, or anything else which you can apply optimization technology to (and there are a lot of things), it must work.  

Why do you think most operations and logistics businesses use legacy software?  It’s a big, difficult choice to change.  They have to be confident the new system will work; they have to make sure employees are trained and ready to use the new system, which is tough when they’re working constantly; and ultimately, the pains of doing all this have to be accepted when they already have some sort of system that works.  If the system merely has a new, improved user experience, the learning curve often outweighs the benefits.

On the other side, it’s tough for new entrants to come to the market - they face all those same challenges in trying to sell to new customers, and eventually they will look elsewhere to easier markets to sell to, or find a new niche.

The great part about an API-based interface is that pretty much all these issues are avoided.  You don’t have to worry about changing your process - you’re just changing one small part of the process, the most painful part.  Instead of needing to be trained on completely new software, with a new workflow, and a new way of doing things, you can just replace one step.  And you can configure the replacement for that step how you like, within the parameters of your current software, processes, and methods.

You can also test out your system, and do some benchmarking against your current methods with little risk - you can simply compare the results of whatever tool you are considering with your standard method.  If the API is set up correctly, and your current software is relatively flexible, this is a simple configuration that shouldn’t take long at all.

Focus for the Company and Team

When you decide to purchase a product, you obviously want the best one.  Or, at the very least, you want the best product for your company or yourself, which may or may not be the same thing.

A lot of the time, however, the best product in a particular category prioritizes depth over breadth.  The opposite is almost always true in the operations and logistics space - software has typically been built to do everything.  There can be benefits to this early in the lifetime of a given market or technology - Microsoft is a good example - but eventually you want specialist products that are flexible, that work well together, but are the best at what they do - modular, in other words.

When you try to build a product that does too much, to have any hope of accomplishing it, you need a team with a broad set of skills, which becomes costly, and distracting.  Usually the result is that you get a mediocre product built by a team that is spread too thin to support things properly and improve the product as they should.

Being API-based eliminates a large part of this equation, and gives both the company, team, and products a narrow focus.  This lets them build great products, support them properly, and focus on what they’re good at.  

In our case, we’re experts at optimization and the related technology.  We recognized that early on, and to build a great user interface would both put us back in the position of overcoming all the barriers we talked about earlier, and in being spread thin with our team.  Instead, we’ve built a small, highly-specialized team that can focus on one thing: building awesome optimization products.

Whether you’re building something for the operations-critical logistics space, or another space completely, it’s almost always better to have a strong focus and specialization for your company and team.  Try to do too much, and you’ll almost always do all of it poorly.

Flexibility in Products

As a company developing products that are API-based, another benefit is the flexibility you retain.  Usually the user interface of a product fits for a specific use-case in a specific industry - you can imagine the logistics context - the crew scheduling interface is going to be far different than the vehicle routing/tracking interface.

For that reason, it’s much harder to test and develop new markets and product lines - instead, you’re usually testing features on the same market, leaving you with the early dilemma of choosing between a market large enough that you can continue to build more features for, and a narrow early market to focus on.

When you’re API-based, you can test new applications, markets, and contexts by just adding a few endpoints, or adapting products behind the scenes - new potential users and customers see the same interface they always have.

In our case, our optimization engine itself is highly customizable, and we’ve spent time examining a lot of different markets and use-cases.  Even now, we’re looking at applications that range from maintenance crew scheduling to routing vehicles, and that’s all possible because the API interface, and the backend products we’ve built are easily customizable on our end.  We can focus on making the optimization engine itself flexible and adaptable to new contexts, without having to build all the front-end software to match.

Conclusion

Hopefully this has helped you understand what makes an API, and the contexts in which they can be used.  If you want to learn more about how they can be used in the context of your own work, I would start by examining the products you already use and asking: which of them provide APIs?  Which products do you use that are built using the APIs of other companies?  How do other companies use those APIs?  Which particular features of each product that you use do you like the most?  Can you access them via an API?

APIs will often provide many possibilities for new use cases, and customizing products for your own particular context - and it may already be possible through existing APIs offered by your software providers.