Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Postman for Server-Sent Event (SSE) APIs

DZone's Guide to

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.

· Integration Zone ·
Free Resource

How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

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.

Make your mark on the industry’s leading annual report. Fill out the State of API Integration 2019 Survey and receive $25 to the Cloud Elements store.

Topics:
integration ,server sent events ,postman ,http api ,api development

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}