Starting with the basics: What is an API?

Like with any amount of business lingo, it is easy to start using a term without properly understanding it. In many ways we have to, as we cannot be an expert at everything. Yet we have to keep up with technology and other fast paced developments in our modern world. This means that some varied level of understanding technical concepts is normal.

However, when planning out and managing an integration project or even as part of business-as-usual, it becomes very important to get more familiar with some common integration terminology. Otherwise, and we have seen plenty of examples of this in our practice, misunderstandings arise and in a worst case scenario, integration projects fail.

Therefore, we have tasked ourselves to create a new series of blogs, explaining the fundamental concepts underlying integration technology. So that we may play a part in elevating discussions about integrations and increasing the reader’s quality of understanding of how integrations work.

After thinking about where to start, we concluded there was only one logical place: the API. Since this is a higher level concept and many integration-related concepts are derived from the API, we have to lay the groundwork first.

What is an (HTTP) API?

An API stands for Application Programming Interface. As a user, you would interact with an application via a Graphical User Interface, or GUI. An API is the interface used by systems and other applications, to interact with the application the API belongs to. The term API is a quite broadly applied, from a small description for a programmer how the inner workings of an application can be used, to a full description allowing third parties to interact with an application.

One level deeper, technically (nerd alert)

When somebody uses the term API nowadays, they actually mean an HTTP API. This is an API that uses Hypertext Transfer Protocol as the communication protocol between the two systems. HTTP APIs expose endpoints as API gateways for HTTP requests to have access to a server.

What does this look like

For example, you use an HTTP API every time you set a Zoom meeting in your Google calendar. The API defines how Zoom can communicate directly with Google’s servers to embed a Zoom meeting into the event rather than having to manually copy and paste the meeting invitation into a field.

HTTP APIs form a broad category, meaning they come in various forms based on their target use case. HTTP APIs are further categorized by the architectural design principles used when they’re created. Most are used for specific IT-related fields, such as hypermedia information systems or web development, and each has particular pros and cons.

What does the API allow the system / application to do?

The API allows for programmatic actions to be made in the application it belongs to. This means that another system or application can read or write, or sometimes even delete data from the application.

Practical examples include:

• Automating data entry
• Automating human activity, where it is standardised and repeatable
• Syncing data between system A and B

How does the API do the programmatic actions?

An API should be documented and built according to a specific standard. Amongst some others, the main ones are:

• SOAP
• RESTful
• GraphQL

These standards deserve separate articles, because there is too much to say about those for this one blog post.

The main point we wanted to make here, is that the standardisation allows for a description of the API that other people can understand. It is as though you would write a manual for how to interact with the GUI of the application for new staff members, but then for other systems, applications and their programmers. This enables the programmers to write code for the API, so the other systems and applications can interact with the API.

Do the different standards imply that there are different APIs out there?

Yes. This is where the common misunderstanding lies that we see in our world. A common assumption is that all APIs are the same and speak the same language. Meaning, that as long as two applications have an API, they automatically speak to each other, or perhaps it's a few button clicks worth of work. This is not true.

Different APIs speak different languages. These need to be translated somewhere in the middle, so the right data ends up in the right place and there are no errors in the process. In a real world analogy, you need a dictionary. Another potentially helpful analogy is that when you travel abroad, you need another plug to access the same electricity as back home. Plugs are not standardised globally, and neither are APIs.

Is there anything else important to know regarding APIs?

One major consideration for everything IT nowadays, is security. Data breaches and other cybercrimes are on the increase, and it is a race where everyone involved in IT projects - including integrations - needs to keep up. This means that for any API, security is important. With an API that is constructed right, there is a lot of opportunity to check authentications and authorisations along the way. This also merits a separate post to give it the space this important topic deserves.

And finally, what are some advantages and disadvantages of working with APIs?

One of the major advantages of working with APIs is that you can have a very flexible IT landscape. You can orchestrate different applications to work together, without needing to create extensive and bespoke applications ‘in the middle’ to do this. You can tweak certain functionality in the process to suit your organisation and its processes better.

Compared to manual or bespoke processes, working via APIs is both more efficient/robust as well as more secure, if done right.

The main disadvantage is the lack of standardisation (as described above) between APIs. There are lots of different kinds of interpretations of how APIs function and this translates in their specific design. This means working with APIs is not straightforward in terms of setting up and maintaining an integration. Contrary to popular belief, it is a niche expertise in its own right. This is why APIs sometimes get a bad reputation, where they are really just poorly understood. Due to this lack of understanding, some organisations have cyber risk exposure they are unaware of as well.

In conclusion

There are lots of other things we can say about APIs. But these are the essential pieces of information we think anyone would benefit from to kick-start their integration project knowledge.

Should you want to discuss anything else API or integration related with us, don’t hesitate to reach out to us here!

Photo by Claudio Schwarz on Unsplash