What is an API?
An application programming interface (API) is a connection that allows apps to communicate with each other. Learn about API types, uses, integration, and more.
An application programming interface or application program interface (API) is an access point through which apps can communicate back and forth. On the most basic level, this allows for the transfer of data without exposing the internal workings of the app.
While the idea originated in the 1940s, the API economy exploded as microservices became more popular in the 2010s. In a microservice architecture, a suite of smaller, loosely coupled services work together to act as a single application, driving digital transformation. To do this, however, those services must interact seamlessly.
We’ll walk you through the ins and outs of APIs, including how they work, what types exist, what purposes they serve, how to integrate them, and more.
How do APIs work?
Pretty much anyone who knows anything about APIs will tell you they’re the software equivalent of a restaurant waiter taking your order, bringing it to the kitchen, and then returning to your table with the food you ordered.
In more technical terms, an API generally serves as a set of rules between an application and a server that governs how they communicate with each other. The defined communication protocol allows apps to be developed, connected, and integrated more quickly and at scale.
Here’s how an API works:
API request: A request originates from a client application and is processed via the API’s management system or the API gateway.
API call: The API’s management system or the API gateway calls the web server or external program.
API response: The server sends the requested information to the API.
API data transfer: The API communicates the data to the client application that requested it.
What are the types of APIs?
The term “API” is often used generically to refer to any API. But the truth is there are several different varieties. They can be broken down by management strategy and purpose.
By API management strategy
Public API: Also known as an open API or an external API, a public API is accessible to any outside developer. Some public APIs are free, but others have a subscription fee. Public APIs often restrict shared assets and have lower authentication measures.
Partner API: Partner APIs are reserved for authorized business partners who have completed an onboarding process and received an official license. This gives the API owner more control over who uses the API and how they use it. Because of their more restricted access, partner APIs tend to have stronger security measures than public APIs.
Private API: Also known as internal APIs, private APIs are used by internal software development teams to enhance productivity by connecting systems and data. They are a scalable solution that makes it easy to incorporate new systems with existing systems. Private APIs are not available to outside users, but some companies eventually make them public.
Composite API: A composite API consists of two or more data or service APIs, allowing access to several endpoints per call. Bundling calls and responses reduces the server load to improve system speed. This is especially useful for a microservice architecture since a single task may need data from multiple sources.
By purpose
System API: A system API extracts data from core systems, such as an ERP or billing system.
Process API: A process API combines data from multiple system APIs to break down data silos and improve agility.
Experience API: An experience API targets user experience by reconfiguring data based on audience and context.
Remote API vs. web API vs. web service
A remote API interacts through a communications network. While not all remote APIs use the internet and an HTTP protocol, many do, which qualifies them as web APIs. That means that while web APIs are also remote APIs, some remote APIs are not web APIs. That said, most APIs fall into both categories.
Similarly, a web service is a variety of API, but not all APIs are web services. To qualify as a web service, it must communicate over a network. Additionally, a web service typically limits access to approved partners and uses SOAP protocol. Hang on to your seats, and we’ll tell you more about SOAP protocol in the next section.
What are the types of API architectures and protocols?
API architectures and protocols control what data the API shares and how it shares that information. Three main options are available:
REST
Most APIs use representational state transfer (REST), which incorporates the following guidelines:
Client-server separation: The client makes a request, and the server responds. This is the only way the two can interact.
Stateless: Each interaction is new and independent, and the server doesn’t remember previous requests.
Uniform interface: A common protocol governs requests and responses.
Layered: Requests and responses must maintain their formatting when passing through additional layers between the client and the API.
Cacheable: A response to a request should dictate if the resource can be cached and for how long.
The resulting APIs may be called “REST APIs” or “RESTful APIs.” They’re usually lightweight, scalable, and user friendly.
SOAP
Simple Object Access Protocol (SOAP) is a data transmission protocol that some APIs use. A SOAP API relies on an XML format and typically receives requests through HTTP. This protocol clearly defines how messages are sent and what information is included, making SOAP APIs more secure but also more difficult to implement.
RPC
Remote Procedure Call (RPC) is a protocol that executes scripts on a server via calls that use either JSON or XML. Since the API security and capabilities are limited, RPC APIs are less common than RESTful APIs and SOAP APIs. That said, they may be appropriate for some internal systems.
What are the uses of APIs?
The uses of APIs are limited only by your creativity. However, many businesses use them for the following purposes:
Expand reach: APIs can help their owners expand their reach and brand recognition. This is particularly true for a public API, around which an entire ecosystem of apps may spring up.
Generate revenue: While some companies offer APIs for free to build relationships, others sell an API key, creating a direct revenue stream. In some cases, APIs can also provide revenue in other ways, such as by creating a sales funnel or distribution channel.
Improve collaboration: The average enterprise uses a staggering number of cloud apps: nearly 1,200. Without APIs to connect them, the information in each application can become siloed, limiting collaboration.
Enhance efficiency and scalability: Since APIs automate data handoff between applications, employees don’t need to go through a time-consuming, error-prone manual process. API integrations can also improve scalability by simplifying the process of connecting systems and applications.
Promote innovation: Because of their flexibility, APIs support innovation. They may allow companies to connect with new business partners, launch new services, and add value.
Improve visibility: A streamlined system improves visibility into processes, allowing for better monitoring and reporting.
What are examples of APIs?
APIs are so standard that you may have utilized one today without even realizing it. While APIs have widespread uses, here are a few common instances you’re probably familiar with:
Travel booking
If you’ve ever looked up airfare on an airline’s website, you interacted with the airline’s API. You requested flight information, and the API retrieved it from the company’s database. Travel booking platforms use even more APIs to access information from multiple hotels and airlines.
Google Maps
The Google Maps API gives developers access to a wealth of geographic data, including interactive maps. Businesses often leverage this tool to give potential customers clear driving directions to their locations.
Universal logins
Many websites and apps allow users to sign in through other platforms and social media, like Google, Facebook, and Twitter. They do this by authenticating users through the services’ APIs, thereby saving users the trouble of setting up a new account and remembering yet another password.
Third-party payment processing
“Pay with PayPal” has become ubiquitous on e-commerce platforms. This API allows users to pay for items without exposing sensitive data.
The Twitter API allows you to filter, sort, retrieve, and view a wide variety of Twitter data, including tweets, places, users, and trends. Companies may use it to monitor sentiment, manage accounts, engage with followers, and more. And while you’re looking to get the most out of Twitter, don’t forget to follow PDQ for the latest in IT.
How do you integrate APIs?
Depending on your company’s needs, timeframe, and budget, several methods are available for integrating APIs. Review the API documentation and assess your goals to decide what is best for your company.
Custom integrations
Custom integrations are developed by a skilled expert to connect existing third-party systems for greater functionality. Since custom integrations tend to be costly and time consuming, they are fading in popularity.
Connector applications
Connector applications serve as intermediaries between popular software platforms via their APIs to help manage and maintain integrations. Because connector applications tend to be affordable and easy to use, they’re quite popular. They may be classified by the app or protocol they support, so you can find options like Salesforce connectors, HTTP connectors, and JDBC connectors.
Integration management platforms
API integration management platforms are typically SaaS applications used to connect other SaaS applications and cloud-based systems. With one request, they can collect and combine data from multiple sources in a single query. They act as Integration Platform as a Service (iPaaS) solutions.
What are common API errors, and how do you fix them?
Most API errors break down into two main categories: request errors and server errors. You can often determine the cause of the error and how to fix it by the HTTP status code.
Request errors
Request errors are generally client-side errors. They have 400-level HTTP status codes, such as the following:
400 Bad Request: This infuriatingly vague message just means something went wrong. Check your request and cross your fingers that you find an issue with your header, query, or body field.
401 Unauthorized: If you’re not authenticated, you could get this error. You may need to sign up and get an API key.
403 Forbidden: While you’re authenticated, you’re not allowed to make the request based on your permissions. This may occur if you try to access features beyond your subscription plan or you use the wrong API key.
404 Not Found: This is the most common error code, and it can have several potential meanings. While it usually indicates something is wrong on the client side, it can also result from a server problem. The first troubleshooting step should be checking the client code for typos.
429 Too Many Requests: API subscriptions often have limits per minute, per hour, and/or per day. If you exceed those limits, you may get this message. Be aware of your limits and consider adjusting your subscription if necessary.
Server errors
If you see a 500-level HTTP status code, you’re probably experiencing a server error. You may need to contact API support to resolve the issue.
500 Internal Server Error: This generally means the API server crashed, but it may be worth checking your docs to make sure everything is right on your end.
501 Not Implemented: If the API developer has not yet implemented the HTTP method you used to request a URL, you may get this status. Trying a different method may yield better results.
502 Bad Gateway: Instead of reaching the API server, you contacted a gateway or a proxy server. While that server attempted to call the API server, the API server did not respond.
503 Service Unavailable: If a server receives too many requests and is overloaded, you’ll get this message. You might try again later.
504 Gateway Timed Out: This status is similar to 502 in that it means you contacted a gateway or a proxy server. However, in this case, the API server didn’t respond quickly enough. If you are requesting a high volume of data, breaking it down into smaller chunks may help.