APIs do work — that’s what they’re built to do. How APIs perform this work can be quite complex, leveraging backend systems and workloads dynamically depending on the situation and use case of each constituent part. Below, we’ll take a look at APIs and workloads and see how they relate to one another. By the end of this piece, you should have a strong understanding of each technology and its applications and use cases.

What is an API?

An application programming interface (API) is the interface that handles communications between different software applications. An API provides a universal language by which services can communicate with resources, allowing systems to work together seamlessly, extensibly, and scalably.

An API works by allowing a system to trigger a specific workload. These workloads take an instruction — say “GET or POST status” — and then activate the database queries or mutations to retrieve that data or process the request.

Types of APIs

There are many different types of APIs, each built with a specific goal or function in mind. Let’s briefly review some of the most common API types in the market, such as REST, SOAP, GraphQL, RPC, and asynchronous formats like webhooks.

REST

Based on the seminal work by Roy Fielding, REST APIs operate upon a model of Representational State Transfer. In other words, the client doesn’t need to carry state and can handle each request individually since the context required to handle the request is packaged in the request itself. Developers often use REST APIs within microservices environments as they’re highly efficient and driven by a contextual system of hypermedia, allowing for additional operations with very little overhead. REST APIs are more flexible than other API types, allowing for various structures and form factors, but this also means there’s less predictability in the end request.

SOAP

Simple Object Access Protocol (SOAP) is an older form of API deriving from traditional centralized flows. SOAP APIs are often referred to as an envelope, whereas REST APIs are referred to as a postcard. A REST API is usually smaller but harder to control, whereas SOAP provides direct control over every aspect of the API. By packaging the instructions and standards within the request, SOAP APIs provide more direct control, which is helpful to certain industries such as fintech or regulatory environments.

GraphQL

GraphQL APIs are a more modern API variation where a schema allows a client to request the data in their request in a specific format or structure. This allows the end user greater control over the resultant output, but this often comes with additional costs in the form of complexity and loss of control. GraphQL APIs are best used with complex data flows and environments where mutation is often needed, and the specific form and function of the data will be determined by the requesting entity.

RPC APIs

RPC APIs, or Remote Procedure Calls, are based on traditional mainframe systems. In essence, you are directly requesting specific remote procedures as if you are dialing into a server and asking it to perform a function. This allows for greater freedom in your infrastructure and processing but is a bit more complicated for complex tasks. This typically centralizes the control on the server side, which can make clients a bit less useful. Or, at any rate, a bit more intense on the learning curve. A variation of this model, gRPC, utilizes an approach pioneered by Google to bring the RPC modality into the modern age.

Asynchronous APIs

Finally, webhooks and PubSub APIs are subscriber systems in which data is driven by the server, not the client. A client subscribes to an endpoint, and when changes to the state of a resource occur, the server notifies the client and pushes the updated data. This is great for resources that seldom change or services requiring more substantial server control over the data structures and flows.

What is a Workload?

As mentioned above, APIs call workloads to do their work. In the context of web APIs, a workload is essentially the total computational and operational tasks that must be fulfilled by a service to fulfill an API request. These workloads typically are composed of several pieces, with varying complexity depending on the specific API structure and service provided. Here are some workload examples:

• Database querying: When an API requests data, a database must be queried. This is handled by the workload to surface information on request.
• Data validation and transformation: When data is surfaced, there may be times when it has to be ported to a specific format, validated, and verified. In these cases, a workload may be triggered to mutate the data before sending it to the end user.
• External integrations: Some systems may not be able to directly answer a query. In those cases, an external service might be tagged to do that work.

These are just a few examples, but workloads take various forms and functions. The key takeaway is that an API is an interface that directly requests a workload.

Types of Workloads

Workloads fall into a few specific types, with variability in application defining their particular attributes. Some common workload types include:

• Transactional workloads: These are the core workload functions that most people will interact with. These workloads are responsive to specific requests, providing services such as user authentication or routing.
• Event-driven workloads: These workloads are triggered by specific actions within the API, such as a file upload or a message receipt. These workloads then notify subsystems of a state change, allowing for rapid system-wide updates.
• Batched workloads: These workloads are typically operations that are combined from multiple sources. For instance, asynchronous APIs that require data processing to occur once all requests have been submitted in a time period may trigger a workload to store those operations and execute them all at the same time.
• Hybrid workloads: These are complex workloads made of multiple types, allowing for complex functionality across the system.

Hosting Options for Workloads

Workloads, like APIs, can be hosted in various locations and form factors. The specific choice for where your workloads operate will largely be determined by the needs of the API accessing them and the services the workloads will need to connect to.

Servers and Local Systems

Workloads can be hosted locally in systems like Apache or other server management solutions. This is common for APIs acting on-premises, as local resource allocation and access are highly critical in such applications.

• Key characteristics: Locally controlled and isolated to the immediate resources on hand.
• Use cases: Local APIs, inter-system services, local hardware on-premises.

Virtual Machines (VMs)

Virtual machines are digital operating systems and hardware pairs created for specific functions. VMs might be created for workloads to provide ad hoc servers and services such as mail server processing, batch processing of cronjobs, and other tasks.

• Key characteristics: Either ephemeral or long-term, digital systems that mirror physical installations with virtual systems.
• Use cases: Best used for variable needs that may be longer-term.

Containers

Containerized solutions package the entirety of the systems needed to function within the given use case. Solutions like Docker allow you to package the code, libraries, and dependencies in ephemeral systems, which can be created and destroyed rapidly.

• Key characteristics: Ephemeral, typically short-term.
• Use cases: Best for ephemeral or short-term systems that must be rapidly created or destroyed. Highly variable data usage can also contribute to economic performance, allowing you to scale only when necessary.

Kubernetes (K8s)

Kubernetes is not really a workload solution in the sense that containers are as much as it’s an orchestration solution for workloads. This popular container scheduler can help manage many containers, providing complex interactions for variable processing and responsive service.

• Key characteristics: Orchestration system that allows for the management of containers.
• Use cases: Highly ephemeral containerized solutions requiring orchestration.

Serverless

Serverless systems create server resources and virtualized systems on an as-needed basis, allowing workloads to be scaled up and down with infrastructure as demand increases or decreases.

• Key characteristics: Temporary and highly responsive to increases or decreases in demand.
• Use cases: Best for systems with huge differences in peak and base load.

Hybrid Systems

Hybrid systems are those systems utilizing any of the previous approaches, or other approaches not listed, in a combination meant for a specific functional need. These are often highly complex and specific to the environment or need in question.

• Key characteristics: Customized to the workload need of the system provider.
• Use cases: Best for variations in service, which make full adoption of any one strategy less effective.

Conclusion

Ultimately, APIs and workloads are intrinsic parts of the same system. Whereas APIs provide connections between systems, workloads are the workhorses of those connections, allowing for advanced functionality.

Choosing the right workload will depend on your specific structure and needs, but workloads can also be highly variable. Accordingly, organizations should focus more on providing the right APIs and infrastructure and resolving the workloads based on their needs.