Websocket Support?

[Lizhooh]

Is insomnia likely to support websocket?

SEO help: AsyncAPI support

[sibbl]

That would be a killer feature, if opening Websockets, reading the stream and sending messages through the UI would be possible.

[gschier]

To be honest, I currently have no plans to support websockets, but I also don't work with them so don't understand how the workflow would be different from regular HTTP requests. I'm also not sure if libcurl supports websockets, which is what Insomnia uses to send requests.

Are there any awesome websocket debugging tools out there? I would love to be enlightened both about existing tools and what your ideal workflow would look like.

[Lizhooh]

Hi gschier.
I hope to have a tool that makes it easy to debug websocket server/clinet.
I've seen a debugging tool for websocket, but it can only debug socket.io.You can look at this tool:
socket.io-tester.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ZigMeowNyan]

Probably one of the major differences would be that websocket, like most messaging protocols, isn't required to be designed around the request/response paradigm. Websockets can stream events, and messages either way might not elicit responses. The connections are much more likely to persist beyond the length of the request.

So you'd probably want some type of persistent connection management. Either with predefined endpoints that you could reference, or with endpoint templates. Honestly, I'd love a few more dimensions in the configuration templating anyway. There are times when I want to flip more switches and turn more knobs than the base and sub-environments allow for. Sub-environments really only let you change one set of values, so you end up with more sub-environments than necessary, or you end up manually changing some values in different environments.

For request/response messages, the interface could be very similar to what it is now. If you're sending your messages slowly and synchronously, it'll work fine. But it's probably not a bad idea to consider an additional websocket data pane that streams the messages as they come in. It'd be handy for things like event subscriptions, Maybe you could check the URI for the ws:// and wss:// (secure) schemes and switch behavior based on that.

With Websocket, you can send several messages at once and be waiting for responses to all of them. Generally users who need to directly relate responses to the original requests over websocket, they'll have some means of doing so in the message itself. For structured messages like JSON and XML, you'd add a property that matches one provided in the request. This could be pretty tricky to implement, as you might need two filters: one for the request and one for the response to pair them. Websockets can also send strings and binary data, which could require more complex logic to parse the messages. For complex binary messages (e.g. protobuf), you might need plugins that understand the logic and can load the definition files. But honestly, just JSON/XML/string support would be a huge step forward. Binary support is a much lower priority, And initial implementations could leave all parsing to the user.

Once you've got a basic configuration interface for event streaming, people could look into adding alternate messaging implementations like socket.io, SignalR or STOMP. Binary message support and protocol definitions (e.g. .proto files) could be another thing to start working into plugins (e.g. gRPC, but implemented over HTTP).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[taybin]

Can we reopen this? It's still a valid request.

[LukeBousfield]

I agree. I think this would be a great idea, and would really help with my testing.

[LukeBousfield]

+1

[oleg-korolenko]

+1

[demidovsky]

+1

[isubasti]

+1

[odwrotnie]

+1

[plashenkov]

+1

[drsect0r]

+1

[freemstr]

@davix postman still does not allow saving websocket calls but Firecamp does
https://github.com/firecamp-io/firecamp

[JCMais]

Recent post from libcurl's author related to WebSockets support https://daniel.haxx.se/blog/2021/09/16/you-wanted-websockets/

[SimonVillage]

This is the most upliked issue here (you can sort by Thumbs Up in the issue list). It's also the only reason which keeps me away from using Insomnia as our team API client.

Would love to see this feature.

[Lizhooh]

Has there been any progress from 2017 to now?

I saw that postman has already implemented support for websocket.

[ooliver1]

anti stale bot bump

[josecsotomorales]

Is this a feature that is coming to Insomnia any time soon?

[hunterhug]

https://daniel.haxx.se/blog/2021/09/16/you-wanted-websockets/

GraphQL Subscription....

[wdawson]

Hey folks! I've converted this to a Discussion with other feature ideas so we can keep track of this better.

We're currently in the process of updating our networking stack, which should start to enable supporting a variety of AsyncAPI protocols. It seems like WebSockets is by far the most popular one. Unfortunately, at this time, we don't have any solid plans to work on this yet. It's definitely something we want to do, but it's a question of time and priority. We'll keep revisiting this as we go, so please keep upvoting!

[toughengineer]

...it's a question of time and priority.

Priority you say?

WebSocket support is only requested for over four (4) years, it is the most liked project issue to date, and the second commented issue to date after the GraphQL explorer one.

Can you please expand on your understanding of "priority"?

Also how much more time do you think you need to add support for it?

[wdawson]

Hi @toughengineer — first of all, thank you for your patience. I know we're more than four years from when this issue was first opened with no progress to show for it. I know that is incredibly frustrating to see. And please, believe me, I'm with you. I want to see this supported in Insomnia too.

The reality for us right now is that the architecture of the application cannot support this. We're working on fixing it but it is a long, uncertain road ahead full of hidden unknowns. I wish I could give you a date for when we'd have the foundation to support websockets and wish even more I could tell you a day when we'd release that support. But I can't.

As I'm sure you're aware, there are many priorities to consider when building software and running a business. For us, that means making our existing users successful and expanding the capabilities of Insomnia to meet the evolving API landscape. I'm sure everyone following this issue will say, "Then you should support websockets!" And you're right! We should. We will. And we're working toward it right now. But until we get a foundation in place that we're confident would provide a good experience, we can't in good faith start working on this directly.

Once again, thank you all for your patience. We appreciate everyone for showing your interest in this capability and we look forward to building it as a team.

[toughengineer]

You could just say something like "adding WebSocket support is not a our priority right now".

[skaihahaha]

+1

[ooliver1]

github has a feature for +1's that do not give many people unexpected notifications

[Murka007]

It would be cool to have websocket support, http and websockets are frequently used together

[quiquelhappy]

why is this still not a thing after at least 5 years of requesting it?

[ooliver1]

IF you read the whole thread you would find #4477 (reply in thread)

[quiquelhappy]

Uhm yeah but also 'Unfortunately, at this time, we don't have any solid plans to work on this yet' from 6 months ago on a feature that was requested 5< years ago

[ooliver1]

Uhm yeah but also 'Unfortunately, at this time, we don't have any solid plans to work on this yet' from 6 months ago on a feature that was requested 5< years ago

Doesn't stop anyone from implementing it themselves, they are not required to implement it for you.

[subnetmarco]

It has now been implemented.

[minhanghuang]

2022 +1

[ooliver1]

#4477 (reply in thread)

[filfreire]

WebSockets are now supported as of version 2022.6.0

[Quentinb]

Spectacular!! just spotted this while adding a new request. @filfreire thanks so much!! Gave it a quick spin and ran into an issue with sub-protocols. The WebSockets I use make use of a sub-protocol (not my choice). I can add the initial required header and the server is happy with this, but Insomnia complains that "Server sent a subprotocol but none was requested" once the socket does the upgrade.

[filfreire]

@Quentinb, this might be fixed in this week's beta release on Thursday if we merge #5238 until then

[Quentinb]

Spectacular, thanks so much @filfreire. Will let you know once I've managed to test it.

[KennethWussmann]

2022.6.0 is great, thanks for that 🎉

Do you think there is any hope for a graphql-ws protocol integration into Insomnia, additionally to the already great GraphQL abilities? While one could of course already work with graphql-ws servers by sending the described messages themselves, but I think it would still be a very neat addition to Insomnia.

Currently I rather use Apollo Studio Explorer for subscriptions and Insomnia for queries and mutations.

[Quentinb]

@filfreire gave the beta version a spin now and the sub-protocol issue is resolved for me now. Working like a charm! Thanks for the work on this!