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:
- REST – Representational State Transfer. This is an API style which is very popular in modern systems. I could go into loads of detail as to what benefits REST brings, but just trust me, it’s good. If your system has a REST interface, it’s going to be easy to interact with.
- JSON – JavaScript Object Notation. This is a standard for formatting data in a text-based structure. You don’t have to use JavaScript to work with JSON data. Most modern technologies can work with JSON, with minimal overhead.
- XML – Extensible Markup Language. Another text-based format for presenting data. It is older than JSON so is typically seen in older systems. The main problem with XML is the complexity of the format, which add extra overhead when processing XML data versus JSON.
- SOAP – Simple Object Access Protocol. Very popular in the 90’s and early 2000’s. This is an API style much like REST is. SOAP started out simple, as the name suggests, but overtime has become bogged down in multiple complicated extensions (MTOM, anyone?) has resulted in any technology that ‘talks’ SOAP needing considerable complexity to cover all bases, and extra overhead (read: reduced performance) in the handling code.
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.
- EDI. Let’s not forget Electronic Data Interchange. This one caught me out at the start of my career. Straight out of university, I was expecting any abbreviation like this to be defining a specific standard or protocol. Nope. Back in the 90’s, EDI meant different things to different people. It’s a principle rather than a specific standard. All of the things I’ve discussed in this article can be considered EDI. If someone wants to know if your system ‘does EDI’, if it’s got some kind of interface or API, then yes it does! Congratulations! What does that mean for you, practically? Not a lot!
- SDK – just for completeness, you may also have come across this one. In the context of APIs, a Software Development Kit makes it easier to programmatically interact with a system. These are usually built for a variety of popular programming languages and are designed to make it easy to work with, with the minimum friction and set up time. The API is the underlying mechanism, the SDK is a layer on top. You can also get SDKs for non-interaction scenarios, so the mere presence of an SDK doesn’t automatically indicate an API, so just be aware of that.
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?
