Postman for Server-Sent Event (SSE) APIs
In this article, we take a look at why developers like using server-sent event (SSE) APIs, and the benefits Postman could bring to the practice.
Join the DZone community and get the full member experience.Join For Free
Who else needs Postman for Server-Sent Event (SSE) APIs?
We are big fans of Postman at Streamdata.io. We use the API development environment to develop, deploy, and test that APIs we use behind the scenes, as well as the APIs we are preparing to make public. Postman is essential to be able to understand what an API does, providing a way to work with the request and responses in a desktop client without writing any code. Allowing API providers and consumers to iterate on the surface area of an API in an environment that allows for iteration and collaboration around what an API does, or doesn't do.
Postman has proven to be an indispensable tool for working with APIs, but we keep hitting the wall when it comes to working with streaming APIs that employ Server-Sent Events (SSE). Unlike Websockets, SSE leverages HTTP to deliver API responses. This is why we use SSE to turn existing web APIs into streaming APIs because it doesn't change the request and response structure, or the transport, beyond just turning each response into a long-running HTTP response, instead of just a single response. Keeping each HTTP connection open, delivering any API updates incrementally as JSON Patch responses, augmenting the original API request with only what has changed. We'd love to be able to use Postman for working with SSE augmented web APIs but the tool doesn't currently support long-running API responses.
There is a GitHub issue opened requesting support for SSE testing in Postman and Newman, so we know the topic is on their roadmap. We wanted to put a story out there further highlighting the potential of working with SSE APIs in Postman, helping drum up more attention to the issue. As the event-driven movement picks up momentum, the need to work with streaming APIs is only increasing. Of course, we are biased a bit on this conversation, but we are actively working to rapidly expand the number of streaming APIs out there, and if API consumers cannot actively work with and test SSE enabled APIs, it creates a problem for us and developers. So, we are looking to connect with other API consumers who are working with SSE APIs and would like to be able to work with them in Postman.
We are hoping to influence the Postman roadmap a little bit. If you are working with SSE APIs and would like to be able to use Postman, make sure to head over to the GitHub issue and make yourself heard. We have our finger on the pulse of the real-time and event-driven API space so we know how many of you are out there, but the Postman team may not. We'd love for all the APIs we are profiling and benchmarking in the Streamdata.io API Gallery have a Run in Postman button, and that button allows for not just executing simple web APIs, but also the SSE enabled stream version of that API, helping work with and test real-time APIs alongside their request and response editions.
Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.