You may have seen an “API” abbreviation dozens of times already. If you’ve ever paid online or used a data aggregator, you’ve used that mystic API. However, what is that? In this article, we look at what APIs are, what API protocols exist, and what types of APIs exist.

What is an API, and how does it work?

Application Programming Interface is a software intermediary that allows distinct applications to communicate. APIs mainly belong to the backend of systems, so you don’t see their work and often don’t know you’re using them right now. 

For example, you visit your favorite news site and see today’s weather forecast. Other similar websites probably offer you the same information. However, where do they get this data? Obviously, news agencies don’t have their weather stations to make forecasts. Instead, they obtain data from a meteorology center. At the same time, a website must serve you an accurate forecast relevant to your location, and thousands of visitors from dozens of places are visiting this particular news outlet simultaneously with you. Developers or website admins can’t manually serve or update forecasts for each visitor. Instead, they use API. Every time you open this website to read news, it uses an API to “call” a meteorology app to know the weather for your location and shows you the app’s response. It’s similar to taking your phone and dialing your friend’s number to get in touch with him. An API is an analog of a “phone number” that apps use to contact each other.

APIs are popular and widely used for good reasons. First, they simplify the development process. Developers don’t have to reinvite the wheel; instead, they can use the same API for many projects. It fastens the development process and consequently saves time and costs. With APIs, apps don’t intrude into each other’s processes; they only get necessary data. As a result, it benefits security, reduces the probability of errors, and contributes to the smooth work of programs. 

On top of that, APIs allow different systems to communicate regardless of their underlying technologies and structure. For users, APIs mean a broad list of functions.

When we speak about APIs, we mainly refer to web APIs—e.g., those that require an internet connection. However, some APIs are used within one system and device (for example, the operating system of a computer) and never need an internet connection. In this article, we focus on web APIs.

Components of APIs

Let’s look behind the stage a little closer. What does this piece of code called API consist of?

The main idea behind any API is interoperability. In other words, any platform that supports the chosen format has to be able to interact with an API in the same way. So, even with different developers and several protocols in use, key components of APIs are the same.

API client

An API client is any app, browser, or software that makes requests. Different things may trigger a client to send a request. For example, a user’s actions, like refreshing a page or pressing a button, could trigger a client to send a request. Conditions that occur at the end and are based on automated logic, such as database queries, could also serve as triggers.

API request

API requests need to follow the same standard. They typically contain five main elements:

Endpoints

Regarding APIs, endpoints are URLs that you direct your requests to. To know what endpoints are available and what format you should use, you must carefully check API documentation, where the API vendor specifies all the details. Usually, endpoints contain the domain name and version of an API you use. They may also contain various query parameters. Again, API documentation includes info about available parameters.

Method

In your request, you must tell a server what you want it to do. So, a method is a command for a server that tells it what to do. Methods differ depending on the API protocol you use. For example, the REST protocol leverages HTTP methods such as GET, POST, PUT, PATCH, and DELETE. Other protocols have their methods. If you are going to use an API, read its documentation, where a vendor clarifies what protocol and methods this particular API uses.

Parameters

Along with query parameters, there are also path parameters, header parameters, and request body parameters. They are necessary for authentication, filtering your request, and passing necessary details to a receiving server. While the method tells the server what to do, for example, retrieve data, parameters help specify what it should pass to you.

Headers

Headers in an API request fulfill a classic role: they provide additional data about the request and desired response formats, authorization details to prove that you’re allowed to take the requested actions, and details about how to cache requests and responses.

Request body

That’s the heart of your requests, where you provide all the primary data using request parameters. To understand it better, imagine a parcel. Endpoints are where you want your parcel to be shipped to. Parameters and headers are other sending data, such as the receiver’s name and phone number, with additional details, such as whether your parcel contains fragile things or whether delivery is paid or the receiver must pay for it. The request body is like a parcel, the box’s content, the things you send. As mentioned, the request body contains different parameters that an API vendor specifies in the documentation.

API server

API server is a platform, software, database, or whatever we send our requests to. It provides the API, stores all the API data, and performs the actions we specify in our requests.

API response

Where there is a request, there is a response as well. A response is what a server sends upon your request. Responses also consist of several building blocks.

Status code

The status code indicates whether our request was successful and whether a server could handle it. Codes in the 200s mean that a request was successful, 300s means redirecting, 400s implies that there were problems with a request, and 500s means there was a problem on the server’s side.

Response headers

Response headers are similar to request headers. They send cookies to a client and provide details about the response body.

Response body

The response body comprises a series of key/value pairs that provide the requested data. However, the response body isn’t a necessary component of an API response. If you wanted a server to retrieve some data and send it to you, you would get a response. At the same time, if you try to delete or replace data on a server, you won’t see a response body; you will only get a status code.

API protocols

A protocol is a set of rules defining how an API works. Several protocols are used for APIs.

REST

REST (or RESTful, The Representational State Transfer) is the most used API protocol. However, it’s more of an architectural style rather than a protocol. It relies on the HTTP protocol to transfer data in JSON or XML formats. Requests are independent of each other, and responses can be cached. Simplicity and scalability are the main advantages of REST, and that’s why it’s the top choice for web services and mobile applications.

On the other hand, over-fetching or under-fetching may occur, so a client gets more data than they requested or, on the contrary, doesn’t get all the necessary data. Also, as REST uses the HTTP protocol, it may not be suitable for all data types, applications, and environments. REST also comes with security concerns; it may have vulnerabilities if it’s not maintained correctly.

SOAP

Simple Object Access Protocol, or SOAP, is much more strict and complex than REST. It uses the XML data standard and can support several protocols for data transferring, including HTTP and SMTP. It supports advanced security features like WS-Security. It’s primarily used for cases that require security and formality over usability by a large audience, like financial services or enterprise applications like Salesforce.

RPC

The remote procedure call protocol handles data in JSON and XML formats. However, it differs drastically from REST and SOAP because it calls method rather than data source. RPC response indicates that an action was triggered or failed. As calling an RPC server changes the state of a server, it’s necessary to have a high level of security between vendors and users. With all of that, RPC APIs are often private ones. However, RPC relies on HTTP/2 protocol to transfer data, which isn’t natively supported in the majority of browsers, so you may need additional equipment to ensure it works correctly.

GraphQL

Though GraphQL is called a protocol, it’s a query language. Unlike REST, which has numerous endpoints, GraphQL usually has only one. GraphQL makes it possible to make multiple requests in a single query. Users may specify what data they need, preventing over- or under-fetching. On the other hand, GraphQL has some challenges with data caching. Also, vendors must provide extensive documentation to inform users what parameters exist for them to make a query.

Types of APIs

There are several ways to categorize APIs—by their target audience or by structure. If we speak about the audience, they can be public, partner, and private, or they may be composite, unified, microservices, and monolithic if we judge by structure.

Public APIs

Also called open or external, public APIs are designed for a broad audience. They have no or little restrictions; even if they require authentication or registration, it’s an easy process, and users don’t need to have any qualifications to use that API. However, open APIs may still require payments or limit features for free accounts. For example, Google Maps API is a public API.

Private API

This type of API is also called an internal API. It is targeted at a small group of users, such as people within a company. Users need permission to access such APIs. They must be secure, so authentication may take time and be complex.

Partner API

Partner APIs are between public and private. Their primary use case is sharing data between two companies or businesses, so such APIs still require authentication and are secure. They are also targeted at a group of users, but that group is larger than in the case of private APIs. Information shared via such APIs is important and definitely not for a broad audience, but it is still not as secret as data shared via private APIs.

Also, sometimes, the fourth type—OpenAPI Standard—is mentioned. However, it’s not another type of API but a framework for writing public APIs. Its original name was Swagger, and this tool provides guidelines, so writing an API and then using it becomes simpler and faster. However, it’s inaccurate to call public APIs ” open APIs” either, as not all public APIs follow the standard. Also, private APIs may use the OpenAPI standard even without being publicly available.

Monolithic APIs

Such APIs are created as a single codebase that grants access to a complex source. Their advantages include predictable functionality and stability. On the other hand, they are hard to scale or update, as a lot of data is connected, and changes could cause unpredictable consequences.

Microservices APIs

On the contrary, microservices APIs have each API serving a different and specific purpose. It’s easy to update them or turn off parts that aren’t needed anymore without affecting the whole system. However, microservices APIs produce an enormous amount of individual requests.

Composite APIs

Here is when composite APIs come into play. They can target multiple endpoints in a single call, identifying the most effective set of calls del, giving you necessary data, and preventing duplicate code.

Unified APIs

Unified APIs are similar to composite; instead of requesting different endpoints on a single API, they request various APIs. The choice depends on your needs.

API testing and monitoring

Like any other software, APIs require testing and monitoring to ensure stability, security, and high-level performance. You can test APIs manually or conduct automated testing. There are several types of API testing:

• functional testing – to ensure that a server responds to requests and responses and data formats are correct;
• load testing – helps validate whether an API works correctly when spikes of traffic occur;
• security testing – necessary to ensure no loopholes for scammers are left;
• regression testing – when changes are made, regression testing is necessary to be sure that no unexpected and unwanted consequences occur;
• fault tolerance testing – good for verifying how a system responds to potentially harmful requests, such as those that may lead to a DDoS attack.

Developers conduct API testing during both the development and deployment stages.

To wrap up

An API is another tool that helps you get the most out of technologies. Though you often use it even without realizing that you do, many functions on your favorite website or app are possible thanks to APIs. In turn, DataImpulse is always here to explain technologies in plain English, so you feel comfortable. Also, powering one tool with another may give you the best result. For example, API testing becomes much more fruitful with proxies. Also, we developed our API, so you can use it to resell our proxies and make money with us. To know more, write to us at [email protected] or press the “Try now” button in the top-right corner of the screen.