When you reassess your API strategy, you may find yourself rethinking your underlying API design style. Is REST still the best? Is GraphQL still valid, or was that just a fad? (spoiler alert: it’s still a good choice!)

According to Postman’s State of the API 2022 report, the most popular API architectural styles are:

• REST (89%)
• Webhooks (35%)
• SOAP (34%)
• GraphQL (28%)
• Websockets (26%)
• gRPC (11%)
• MQTT (9%)
• AMQP (8%)
• Server-Sent Events (6%)
• EDI (4%)
• EDA (3%)
• Other (1%)

With this in mind, let’s take a look at the most popular API architecture styles for 2023. We’ll outline the pros and cons of different API architecture styles, like REST vs. GraphQL, to help you decide which architectural style you should consider for your next API development project. Without further ado, here are the top API architecture styles of 2023.

The Top API Architecture Styles of 2023

REST

REST was one of the first standards for APIs, as laid out in Roy Fielding’s dissertation, and it remains one of the best. REST is also the most popular, by far, making up a mammoth 89% of APIs.

REST stands for REpresentational State Transfer. It’s a standard that lets users make API requests using simple HTTP commands. REST’s serverless architecture allows for easier decoupling between user and server, making it excellent for abstraction. It can also support a wide range of data formats, so it’s quite flexible as well as scalable.

REST is not without its downsides, though. It returns a lot of metadata, for example, which can slow down response time and use up unnecessary bandwidth. This large format, along with issues regarding overfetching and underfetching, is one of the main reasons that Facebook developed GraphQL in 2012.

Webhooks

Sometimes we need real-time data interactions. Perhaps it’s best for the application to automatically receive the latest updates instead of manually querying the API. Webhooks solve these situations for you.

A webhook can be used to send data whenever a new event occurs. For example, imagine you’ve set up a new email list and want updates whenever you get a new subscription. A webhook can transmit that data, saving you the time, effort, and energy of making a query. This can also prevent wasting unnecessary resources making API calls when the data hasn’t changed.

The main downside of webhooks is they’re not as versatile or customizable as a fully-fledged API. It’s simply a one-way data transmitter. There’s also no indication if the receiver is working, so you won’t necessarily know if the data being transmitted isn’t getting where it’s supposed to go. Webhooks have all manner of useful applications, though. You’ll just want to have a monitoring solution in place to ensure you’re notified if something goes wrong.

SOAP

SOAP is an XML-formatted structure standardized by W3C. It’s the most widely used format for web services and useful for a vast number of different applications. SOAP is also excellent for privacy, allowing for encrypted messages and integrity inside each transaction.

However, SOAP is the biggest file format due to the verbose XML structure. SOAP is only appropriate when large bandwidths are available. It’s also very rigid, though, so it’s not very customizable, which significantly slows down its widespread adoption.

GraphQL

Facebook’s GraphQL has a lot going for it. Its simple, JSON-like data structure is easy for non-technicians to understand and use. GraphQL is database-agnostic, meaning you can use it with virtually any database you can think of.

This makes your API eminently scalable and portable. These traits are key to an API’s widespread adoption and ultimate success. GraphQL is also excellent for privacy, as it will expose certain functions while leaving the rest of the data secure. It also has detailed error logs, which are useful for large and unwieldy APIs.

GraphQL’s not the best choice for complex queries, though, as too many nested queries can cause an overload and system shutdown.

WebSockets

If you want the advantages of webhooks but also want two-way communication, WebSockets are the way to go. Like webhooks, WebSockets provide real-time data transmission. They’re also able to receive data, making them the best of both worlds. WebSocket connections are much faster than HTTP, as well, so they’re a great pick if you’re looking for the fastest connections possible.

However, WebSockets have problems, which explains why they’re not more popular. They’re especially rigid, for one thing, unlike other API architectural styles. If a WebSocket goes down, there’s no load balancing or mechanism for reconnecting. They also don’t support caching, unlike HTTP. Many proxy servers don’t support WebSockets, either. This means you often have to have an HTTP streaming infrastructure in place in tandem with your WebSockets.

gRPC

For all of its many strengths, REST is not the fastest or most efficient API architecture out there. In fact, gRPC is 7 times faster. gRPC also has a native code compiler, removing the need for third-party tools. Based on HTTP 2, gRPC is also ideal for microservice environments and useful for data streaming.

One thing to keep in mind, however, is that gRPC uses the Protobuf format instead of JSON. Protobuf is lightweight and efficient due to its data compression. It’s not as understandable by humans, however. It’s also not as widespread as JSON, either, so you might need to put a translator in place if you’re integrating gRPC APIs into other API environments. gRPC is also more complicated and harder to implement than other API architectures. If you’re looking for something that’s fast and easy to set up, you’d do better to go with another API architectural style like REST.

MQTT

MQTT is a useful API architecture for IoT applications. It’s popular for being lightweight and having low battery usage. It’s also popular for its messaging accuracy.

Unlike other API architectural styles, MQTT doesn’t use HTTP for sending or receiving requests. Instead, it uses TCP/IP and a “publish-subscribe” model. This means the receiver needs an MQTT Broker to integrate with the device using MQTT, which acts as a sort of post office for MQTT messaging.

MQTT is limited in its functionality, though. It can only send and receive basic requests and file types. It’s also not as interactive as REST, lacking the ability to POST, GET, DELETE, or PUT. With this in mind, MQTT is mainly appropriate for IoT applications specifically. It’s also suitable for situations with limited connectivity or low bandwidth.

AMQP

AMQP is an API architecture designed for microservices. AMQP stands for Advanced Messaging Queuing Protocol and is intended to be used whenever massive amounts of data or messaging are required.

AMQP is an amalgam of a few of the API architectural styles we’ve already discussed. It uses the publish/subscribe model of MQTT, for example. Its use of wire-level signals allows for continual data streams, making it similar to webhooks and WebSockets. It utilizes TCP like MQTT, too. AMQP is particularly secure as it uses the Quality of Service (QoS) protocol. It’s also particularly adept at handling asynchronous messaging, regardless of OS.

AMQP has its share of drawbacks, though. It’s not backward compatible, for starters, so you’ll only be able to integrate with the current version. It’s also more complicated than HTTP. It also requires higher bandwidth than MQTT.

Server-Sent Events

Server-Sent Events (SSEs) are like a mix of webhooks and WebSockets but with many limitations removed. It offers the efficiency and connectivity of webhooks and WebSockets but also provides automatic reconnection should something go wrong.

SSEs use XHR to stream data over HTTP, making it a practical choice for projects requiring real-time data, such as weather apps or stock services. SSEs are fairly easy to set up and use and are accepted by most major browsers since they’ve been in use for years. But if it’s not yet supported by the particular browser, it can be poly-filled using JavaScript.

The downside is SSEs are not that prevalent so there aren’t that many libraries available, unfortunately. They support a limited range of data, too, and only transmit UTF-8. Additionally, browsers can only support a maximum of six SSEs simultaneously. Finally, SSEs are only uni-directional, so their usefulness is limited and specific, usually to real-time apps.

EDI/EDA

EDI stands for Electronic Data Interchange, and EDA is shorthand for event-driven architecture. Both offer powerful capabilities for data transfer in different ways.

EDI has been around since the late ’70s. It uses a P2P network to transmit large quantities of standardized data. It’s pretty straightforward to use and widely available, thanks to its longevity. Like AMQP, EDI isn’t backward compatible, unfortunately. Three versions of EDI are available, and each only works with the same version.

EDI is also much more limited in its scope and usefulness, unfortunately. It’s more like a tunnel than an exchange, as it can only connect two users. It’s also relatively expensive and cumbersome to implement.

EDA has also been around since the ’70s. It’s a fairly simple concept, similar to webhooks in many ways. When something happens, something is triggered. EDA is also inherently scalable — events can be queued and retrieved at a later date. Subscriptions can be turned on and off, as well, making EDA useful for “pub/sub” or “publish/subscribe” applications.

You always need to be careful with real-time applications, though, as there are no built-in guardrails. If EDA is connected to a service that charges per transaction, this can quickly become a costly mistake. It can also cause performance issues, depending on the amount of traffic at a particular time.

Final Thoughts On API Architecture

As you can see, there’s much more to APIs than just REST, although that remains the leader by a longshot. It’s safe to say that as things like microservices, headless and serverless solutions become more prevalent, we will also see increased adoption of some of these alternate API architecture styles.

Even if you stick with REST, it’s still good to know what’s out there and what your options are for API development. Maybe you’re developing an IoT portal or dashboard, for example. In that case, REST might not be the best for that particular application, and you might be better served using MQTT or AMQP instead.

When choosing your API architecture style, you’ll want to think about what kind of libraries and third-party applications are available. You’ll also want to consider how widely used it is, as you’ll want others to be able to use your API, as well.

One thing is for certain: the API landscape is growing and evolving. It’ll be fascinating to watch what the next 12 months have in store!