Engineers are often faced with the challenge of integrating two or more applications, via their APIs, to let those systems exchange data.
As APIs become increasingly complex and more widely used, it is essential for engineers to have an understanding of how to integrate them properly.
This guide will provide an overview of what API integration is and how it works. We'll also discuss the different types of APIs that you can use to build your own applications. Finally, we'll look at some tips on how to get started with API integration for engineers using the n8n automation tool.
Table of contents
- What is API Integration?
- How many types of API are there?
- How to build an API integration?
- API integration with n8n
- Wrap up
What is API Integration?
To understand API integration, let’s start from the top and first of all answer an obvious question.
What is an API?
An API sits between two systems allowing them to exchange data seamlessly whilst abstracting the low-level details of the interacting systems from each other.
Following our definition of APIs, it’s easy to think that an API is a standalone system that is separate from the two systems, but no, it’s not. APIs usually come built into the systems that expose them. Not clear?
Okay, for example, let’s take Twitter APIs.
When we talk about Twitter’s APIs we are talking about the different interfaces that Twitter exposes, through which other applications can send data to or receive data from Twitter.
So, when we talk about Twitter’s API, we are not referring to an entirely separate system that sits between Twitter and other applications needing to communicate with it. Instead, we are referring to a component of Twitter that provides some service to other applications. ‘Service’ here is any task that Twitter performs which is of utility to another application or user. For example, an application might want to access Twitter’s trending tweets from its API.
Stretch the above example to other software systems and you have your definition of an API – the set of functions that allow an application to interact with other external systems. The interaction here implies sending or receiving data as well as requesting the external system to execute some task.
How does API work?
Recall that APIs essentially allow two systems to communicate – the communication between these two systems each having its API usually happens in the following order:
- You’d have a system, system A, that connects to the API of another system, system B.
- System A makes a request to the API of system B.
- The API of system B passes the request to some business logic in the system that then processes the request.
- Finally, the API of system B then returns the result of that processing to system A.
In the API parlance, the system making the request is called the client, the system serving the request is called the server, and the result returned to the client is called a response.
How many types of API are there?
The different categories we put APIs into would depend on the intent. For example, if the intent is to categorize these APIs based on who the API is intended for, then we can tag an API as either being public(available to everyone), private, partner, etc.
However, if we are categorizing these APIs based on their architectural style and protocol then we can put APIs into two broad categories: web APIs and non-web APIs.
Web APIs require some sort of network, for example, the internet to be interacted with. Most times when we talk about APIs, we are referring to web APIs – they are the most common. Non-web APIs on other hand do not require the internet – think browser APIs.
In this piece, we are particularly interested in web APIs, so let’s explore the concept further.
Web APIs
Recall we mentioned that an API is the component of an application through which that application talks or provides some service to other applications. An API is considered a web API if it talks to or provides service to other applications over the internet.
REST APIs and how they work
REST stands for Representational State Transfer. It is an architectural style that defines the set of guidelines, formerly called constraints, for designing an API. Essentially, APIs that are designed within the bounds of these constraints are considered RESTFUL.
At the core of the REST architecture are clients, servers, and resources. Clients and servers had already been explained in one of the previous sections but what is a resource?
A resource is any object that the API provides some information about. For example, in Twitter’s API, the user is a resource, and a tweet is also a resource.
Essentially, in the REST architecture, clients call the API and the server that owns the API sends to the client a representation of the state of the requested resource.
Let’s take an example.
When a client calls Twitter’s API to fetch a specific user (the resource), the API will return the state of that user, including their name, their tweets, how many followers they have, and more.
Even though the example above showed an instance where the client only needs to retrieve some information about a resource(the user), the client could actually do more than just retrieve information about a resource.
What a server (in this case Twitter) does when a client calls one of its APIs would depend on two things provided by the client in its request:
- A unique identifier for the resource the client is interested in. This unique identifier is formally called the Uniform Resource Locator(URL) - the URL points to the location of a resource on a given server.
In the REST parlance, you’d often see the URL of a resource referred to as an endpoint. For example, the endpoint that returns information about a user with the username, nyior, could look like something like this: www.twitter.com/nyior
2. The operation you want the server to perform on that resource, in the form of an HTTP method, or verb.
GET - tells the server to retrieve a resource and return it to the client
POST - tells the server to create a resource on the server
PUT - tells the server to update the specified resource
DELETE - tells the server to delete the specified resource from the server
There are other http methods but these are the common ones.
Thus, as seen in the image above, the fundamental requirement for calling an API is that the request from the client to the server must specify an endpoint/URL(that signifies the resource of interest) and the HTTP verb that tells the server what action to perform.
For example, an API call with curl to Twitter’s endpoint for grabbing a user would look like this:
curl -u <API key>:X -H "Content-type: application/json" -X GET "https://www.twitter/api/nyior"
In addition to the usual endpoint and HTTP verb, a typical REST API request from a client would also carry some extra metadata in the headers. In the case of a POST request where some resource is created, the request must also carry the new data to be created - the payload.
How to build an API integration?
There are two ways to build an API integration:
- Creating custom integrations with written code
- Using API integration platforms
Creating custom API integrations with written code
As its name implies, this requires manually writing code that stitches two or more applications via their APIs to allow them to communicate.
While integrating applications this way works, it is fraught with a myriad of issues.
First, it is generally time-consuming – developers would spend time implementing this custom code and maintaining the code over time. Secondly, this approach is not easily scalable – it is easy to do when connecting let’s say, just two applications, but things quickly get complex when connecting there is the need to set up a more complex integration that spans across multiple applications.
In the beginning, this was how APIs were integrated, but recognizing the inefficiency of this approach, API integration platforms were created.
Let’s quickly look at implementing API integrations using these platforms!
Using API integration platforms
Generally speaking, API integration platforms exist to eliminate the need to write lots of code to tie applications together via their APIs. In other words, these platforms allow the setting up of an API integration via a graphical user interface with very little or no code at all.
You’d find two classes of API integration platforms:
- Lightweight API integration tools for small and medium businesses (SMB): These are tools with graphical user interfaces, which can be easily operated by non-technical individuals. The tools in this category are designed to often meet the needs of small and mid-sized businesses. As a result, they may not be suitable for advanced workflows and more complex integrations. Examples are Zapier, IFTTT.
- Advanced API integration tools for complex workflows: The tools in this category usually have a more comprehensive set of features, but they often require programming skills. This can be problematic for non-technical persons whereas being a flexible solution for technical people who want to build customizable integrations. An example is n8n.
API integration with n8n
To begin, let’s quickly look at how n8n works in the context of API integration.
n8n is a workflow automation tool. Think of a workflow as some major process you would want to automate. At the core of every n8n workflow are nodes. Think of a node as a sub-task or step in the larger process.
For example, think of a scenario where you need to set up a two-way data sync between Pipedrive and MySQL.
If as we have mentioned, each sub-process in a workflow is represented by an n8n node, then we are going to have several nodes linked to each other in our Pipedrive and MySQL workflow. For example, we will have the MySQL and Pipedrive nodes in our workflow amongst others.
From a more technical standpoint, these nodes serve as an entry point for retrieving data, a function to process data, or an exit for sending data. The data process performed by nodes can include filtering, recomposing, and changing data.
This begs the question, how do these nodes retrieve data?
Well, the nodes (integrations) that you see use APIs provided by different services to allow you to interact with these services within your workflows.
Thus, in our case, our workflow will interface with the APIs of Pipedrive and MySQL via the Pipedrive node and the MySQL node respectively. Keep in mind that to work with this workflow you need to configure the credentials for the Pipedrive node and the credentials of the MySQL node.
With this Pipedrive to MySQL integration you can keep data in sync – meaning, when you update shared data in one of the platforms, it automatically gets updated on the other platforms. It demonstrates an obvious benefit of API integration with n8n.
This bidirectional data sync powered by API integration also helps to preserve data integrity - this is true because data has to be updated in only one location.
Wrap up
API integration is an essential part of modern software development. By integrating APIs into your software, you can quickly connect to other applications and services, enabling tasks automation, data access from third-party sources, and creating a more efficient workflow.
In this article, you've recapped what API-based integration means, what API types are available, and how to set up API integration using the n8n workflow automation tool.
What’s next?
In the example of API integration with n8n, we focused on the Pipedrive and MySQL workflow, but there is a lot more you can build using Pipedrive API integration or MySQL API integration! For example, you can implement a PayPal integration or a QuickBooks integration.
Ready to turn your routine tasks into automated workflows?
Sign up for the n8n cloud account to easily get started and start automating processes with n8n!
The platform also offers hundreds of pre-built integrations and hundreds of automation templates, allowing your team to design the custom workflows you need.