Site icon Software Solved

What is Application Programming Interface (API)?

If you’ve been near any sizable software system, you may well have seen the phrase ‘API’. What’s that all about? ‘API’ stands for Application Programming Interface, but does that make it any clearer?

APIs are ways to exchange information between two or more systems. They provide a well-defined ‘shop front’ for each system to interact with. The calling system doesn’t need to know all the fine details as to how the information is stored or how to get it itself, it just asks the API, and the requested data is returned. The calling system could also be sending data to another system. It just sends that data to the API and the other system saves it. You can also trigger some processing to occur by an API call. In that way, it is a bit like ordering a meal at a takeaway. You go to the takeaway counter and place your order. You’re not having to ask for each ingredient separately, going to get it yourself, and you’re not having to specify for a certain recipe to be followed in a certain way, you just ask for the cooked meal and after some time it’s presented.

So we’ve discussed what API stands for, but there are loads of other acronyms that often crop up:

These are all technical implementation details of an API. The key thing to be aware of is that XML and SOAP interfaces are more complicated. REST/JSON APIs are easier to interact with. Most programming languages can work with all of these, but the reduced complexity of REST and JSON mean that they are much more popular these days.

So… why would you care? It’s all about integrations between systems. If you’ve got a CRM or ERP/line of business system and need to get the data in that system over to another system, or trigger something in another system when a record is added in the CRM system, having APIs in those systems allows for that integration. This saves you running manual processes to update other systems, re-keying data, taking lots of time and introducing lots of opportunities for mistakes, missing data, duplicates etc. At a high-level, having these facilities reduces manual work and reduces the chance of mistakes occurring. You also open up the opportunity to bring data from different systems together, improving cross-department reporting and KPIs.

There are several technical ways that systems can be integrated, with direct integration at the database being one that has been used for ages. However, without a well-defined integration point like an API, systems and those integrations end up being far too dependent upon the underlying way a system is built, which will cause all sorts of grief down the line when you’re looking to upgrade one of those systems. Going back to the analogy earlier, if you go into a takeaway and always ask for some food, specifying exactly what ingredient they can use and to what recipe, if that takeaway changes their menu or perhaps the business changes hands and the new owner changes the style of food served, suddenly your order makes no sense. That’s the type of integration where one system talks directly to the underlying database of another system. If you went into the takeaway and ordered from the menu (the published API specification) then the interaction will continue to work. Maybe the owners will still offer the old menu while they transition to the new style of food. This is called API versioning and really helps with those big system interactions – allowing upgrades of one system while not breaking integrations with another.

So, when looking to implement a system, whether that’s a software package or a custom system, do take some time to think about more than just what problem the system solves, but also where is that data going? How does it fit into your wider business? What support does that new system have for these integrations?

Exit mobile version