In the ever-evolving landscape of software architecture, two prominent paradigms have emerged that cater to different needs and applications: Representational State Transfer (REST) and event-driven architecture (EDA). While REST has become the de facto standard for web services, encapsulating resources into simple and stateless interactions, EDA remains a strong option for the asynchronous handling of events.

These two architectural styles, although fundamentally different in design and execution, are central to modern software development. From web applications and cloud storage to real-time analytics and IoT systems, REST and EDA play vital roles in shaping how we interact with digital technologies. Below, we’ll dive into the principles, design paradigms, and pros and cons around both REST and EDA to unravel their unique characteristics.

What is REST?

REST, or Representational State Transfer, is a paradigm wherein REST APIs, utilizing a set of standardized methods, can be used by the end user to interact with data remotely. RESTful APIs typically adopt HTTP verbiage, including methods like GET, POST, PUT, and DELETE.

Broadly speaking, REST is considered a request/response system, also referred to as client/server, and allows for such a system without tight coupling. In practical implementations, RESTful services are often built around microservices, which are collections of small RESTful APIs that break out functionality into smaller services rather than adopting a monolithic solution.

REST has a set of specific constraints that define what is truly RESTful. These include:

• Client-Server Definition: Clients and servers should be separate from each other in terms of abstraction and interaction. In other words, clients should not have to concern themselves with server functions outside of their request, and servers should not have to record any sort of state. The client and server should be abstracted and separate, allowing for development upon one without fundamentally breaking the interaction between the two.
• Uniform Interface: The service should be decoupled from the architecture, self-descriptive, manipulatable through representations, and linked through hypermedia.
• Stateless: All the data necessary information for interacting with the service should be within the request itself. This means, in practice, that the state of the interaction should be internally defined within the request and should not depend on the state of prior interactions or internal systems to function.
• Cached: Cached content, that is, copies of frequently accessed or utilized data, should be stored throughout the request-response path, allowing for more flexibility and scalability and abstracting the interaction from the server state.
• Layered: The interaction between server and client should function either directly or through layered systems efficiently. The client and the server should not concern themselves with intermediary systems, allowing for stability, load-balancing, and shared caching.

REST is typically a synchronous system. While some implementations may, in practice, feel or look like something other than REST, the underlying systems may still be RESTful.

Pros and Cons

One of the main benefits of REST is the fact that it is highly scalable. Since RESTful implementations have decoupled servers and clients, these implementations can be scaled quite effectively. Additionally, REST is language agnostic, allowing implementations to vary widely depending on specific use cases and needs.

That being said, REST is largely limited to stateless operations: stateful implementations are not appropriate on a REST platform. This is doubly so in the case of transactional systems that require complex and continuous states to be recorded, as this stateful paradigm is counter to the ethos and approach of REST itself.

What is Event Driven Architecture (EDA)?

Event Drive Architecture, or EDA, is exactly what it sounds like — an architecture that is based on the concept of an event that drives interactions or results. This event can take a variety of forms, and the nature of how these events are communicated to the end user is often the most significant defining element of the EDA implementation.

State changes that result in an event can be communicated through many different systems, but the two most common paradigms for these systems are pub/sub and produce/consume. In the pub/sub paradigm, a user subscribes to a service that publishes changes, and when such a change is issued, the subscriber is automatically notified through an endpoint service. In the produce/consume model, the producer often collects these events and either publishes individually or as part of a stream, which the end user interacts with in the form of a consumption model.

EDA is typically considered an asynchronous system. While there are caveats, as with REST, most greenfield EDA systems could be defined with only minor drawbacks.

Pros and Cons

EDA can be highly flexible for the server side of things. Since functionality driving events is entirely separated from the client experience, the server can iterate rapidly as long as the mode of alert does not change. For this reason, EDA is often also much more efficient for a user who simply wants to be updated when a change is detected. This removes unnecessary polling. When no additional processing is to follow, EDA is by far the simpler implementation.

That being said, EDA is entirely asynchronous, meaning that any interaction that requires synchronized communication will not find EDA helpful. Rearchitecting preexisting RESTful platforms into an EDA world can also be tricky. Additionally, ensuring consistency across all events can be somewhat challenging when those events differ foundationally.

Real-World Applications

RESTful implementations can be found all across the internet. Many of the most common APIs for end consumers are RESTful. A great example of a RESTful API is the Twilio Voice API. This API allows users to make and receive calls as well as edit the metadata around those calls. Various additional functions, including conference calling, call recording, and much more, are made available through a RESTful interface that leverages microservices to scale and extend.

On the other side of things, a great example of an EDA implementation is the Google Cloud Pub/Sub API. This API connects users to a large event processor, creating a system for event ingest. This system is more of a facilitator than a first-party API. In other words, the system connects clients to servers hosted on Google Cloud’s platform rather than to an internal generator of events, as other EDAs might.

Apache Kafka is another example of this model. It’s a distributed streaming platform that enables users to subscribe, publish, store, and process data streams. The main benefit of something like Kafka is that it decouples data production from consumption, opening up a wider range of large-scale data processing in an EDA environment.

Some common technologies used within the EDA pattern include:

• Message Brokers/Event Buses
  • RabbitMQ: A widely adopted message broker that uses Advanced Message Queuing Protocol to control messages.
  • ActiveMQ: An open-source Java message broker that utilizes multiple protocols.
    Azure Event Hubs: A managed event stream using Microsoft’s Azure Cloud service.
• Event Streaming Platforms
  • Apache Flink: A stream-processing framework with event-time processing and stateful computations.
    Apache Beam: A unified batch and data stream processing platform.
• Complex Event Processing Systems
  • Esper: An engine for streaming analytics and Complex Event Processing.
• Event Notification Systems
  • AWS SNS: A Simple Notification Service (SNS) based on the Amazon Web Service that coordinates and manages the delivery of messages for clients through subscription endpoints

Conclusion

REST and EDA are two compelling systems with very different use cases. While REST is excellent for synchronous data exchange, EDA is more appropriate for publisher/subscriber relationships and paradigms that are heavily event-specific. While REST is commonly used for web services with stateless operations, EDA is best in scenarios that demand more flexibility in communication. Choosing between them hinges on the specific needs and characteristics of the system being developed.

Did you find this helpful? What else would you like compared? Let us know in the comments below!