Do you use Postman? Here is how it would fit in your event-driven system
# What is Postman
Postman is an API management platform that gives users the ability to build and test APIs. At its core, Postman is a REST API focused platform and is super developer friendly with CRUD operations where you can GET and POST using REST APIs. Postman has the notion of Collections where you can bundle REST APIs into one folder that reflect a common business logic.
# How do you bridge Postman into the EDA world?
Good question! One way to bridge the Synchronous REST world in Postman with the Asynchronous Eventing world using Solace PubSub+ Event Broker is via leveraging the native protocol translation and interoperability that comes in the broker. What do I mean by that? A picture is worth a 1000 words!
As you can see in the diagram above, we can send HTTP POST requests into the broker and it can be translated into events in the messaging world. This is what we call event enabling REST.
# Event enabling REST Architecture
Taking what we know about the native REST support in the Solace PubSub+ Broker, here's how you can integrate your EDA design with your Postman workflow to mock and test your Event API or applications subscribing to events. This came out from an initiative to supercharge the software development lifecycle with PubSub+ Event Portal
You can read more about it here.
# Install Event Portal to Postman Collections converter
Assuming you have already designed your event driven architecture using PubSub+ Event Portal with an Application Domain that has applications, events, and schemas, start with installing and configuring the cli tool from this repo.
After running the cli tool, a Postman collections is generated that reflects the designed application as a Postman collection and all the subscribe events involved in the applications are converted into POST requests with the topic hierarchy in the URL following the Solace conventions. Importing the generated collections file into Postman will give you something similar to the following screenshot.
Things to note:
- The URL reflects the topic hierarchy of the events the application subscribes to
- Dynamic variables in the topic are converted into Postman variables
- Authentication is defaulted to a localhost solace broker unless otherwise specified
- The payload body of the POST request is generated from the payload schema of the event
# Publish events
And that's about it! Executing the POST request will simulate an event published to the application you are mocking.