starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #3311] [feature]: allow saving websocket messages (commands) into collections #1098

New issue

Open

opened 2026-03-16 18:33:04 +03:00 by kerem · 6 comments

kerem commented

2026-03-16 18:33:04 +03:00

Owner

Originally created by @SamJakob on GitHub (Sep 3, 2023).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/3311

Is there an existing issue for this?

I have searched the existing issues

Summary

Similarly to how HTTP/REST requests may be saved to collections, it would be beneficial if WebSocket messages could get the same treatment.

I think this could be handled in one of two ways:

(preferred) save the endpoint (URL) and the body of the message into a collection entry.
- When the entry is selected by the user, update the current endpoint to the specified URL.
- Disconnect from an existing web-socket endpoint if already connected to one. Then, either way, if not connected to the endpoint, connect to it. (In other words, connect to the associated endpoint if not already connected).
- (Whether the endpoint is automatically connected could be made into an option in settings).
(alternatively, but less usefully), simply save the body of the message
- When the entry is selected set the current message body to that which was selected

Why should this be worked on?

When developing (and particularly iterating) WebSocket-based APIs, it is often necessary to re-input the same commands (which may be fairly long and non-trivial). This would improve the UX of doing so (as presently one must resort to having a list in a text document).

It would also lend itself to being able to better document and demonstrate WebSocket APIs.

Originally created by @SamJakob on GitHub (Sep 3, 2023). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/3311 ### Is there an existing issue for this? - [X] I have searched the existing issues ### Summary Similarly to how HTTP/REST requests may be saved to collections, it would be beneficial if WebSocket messages could get the same treatment. I think this could be handled in one of two ways: - _(preferred)_ save the `endpoint` (URL) and the body of the message into a collection entry. - When the entry is selected by the user, update the current endpoint to the specified URL. - Disconnect from an existing web-socket endpoint if already connected to one. Then, either way, if not connected to the endpoint, connect to it. (In other words, connect to the associated endpoint if not already connected). - (Whether the endpoint is automatically connected could be made into an option in settings). - _(alternatively, but less usefully)_, simply save the body of the message - When the entry is selected set the current message body to that which was selected ### Why should this be worked on? When developing (and particularly iterating) WebSocket-based APIs, it is often necessary to re-input the same commands (which may be fairly long and non-trivial). This would improve the UX of doing so (as presently one must resort to having a list in a text document). It would also lend itself to being able to better document and demonstrate WebSocket APIs.

kerem added the

feature

label

2026-03-16 18:33:04 +03:00

kerem commented

2026-03-16 18:33:15 +03:00

Author

Owner

@0bvim commented on GitHub (Dec 27, 2024):

@SamJakob Can I work on it?

@0bvim commented on GitHub (Dec 27, 2024): @SamJakob Can I work on it?

kerem commented

2026-03-16 18:33:20 +03:00

Author

Owner

@SamJakob commented on GitHub (Dec 27, 2024):

@0bvim - sure!

@SamJakob commented on GitHub (Dec 27, 2024): @0bvim - sure!

kerem commented

2026-03-16 18:33:25 +03:00

Author

Owner

@0bvim commented on GitHub (Dec 29, 2024):

@0bvim - sure!

@SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong?

@0bvim commented on GitHub (Dec 29, 2024): > @0bvim - sure! @SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong?

kerem commented

2026-03-16 18:33:30 +03:00

Author

Owner

@SamJakob commented on GitHub (Dec 29, 2024):

@SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong?

From memory, yes. I never got any feedback on it so I'm not sure if merging it was ever considered.

Also there's a handful of merge conflicts now that will need to be resolved (hopefully nothing major?).

@SamJakob commented on GitHub (Dec 29, 2024): > @SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong? From memory, yes. I never got any feedback on it so I'm not sure if merging it was ever considered. Also there's a handful of merge conflicts now that will need to be resolved (hopefully nothing major?).

kerem commented

2026-03-16 18:33:35 +03:00

Author

Owner

@0bvim commented on GitHub (Dec 29, 2024):

@SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong?

From memory, yes. I never got any feedback on it so I'm not sure if merging it was ever considered.

Also there's a handful of merge conflicts now that will need to be resolved (hopefully nothing major?).

Idk the tools used in the front-end and I am 'new' in the area and I work with back-end for now. I am doing a project that has websocket calls, but I need to save them in the collection to be able to make them available to the public. Could you resolve these conflicts or could you give me some direction on what I can do?

@0bvim commented on GitHub (Dec 29, 2024): > > @SamJakob I looked at the PR and basically all that's left is to review what was done, or am I wrong? > > From memory, yes. I never got any feedback on it so I'm not sure if merging it was ever considered. > > Also there's a handful of merge conflicts now that will need to be resolved (hopefully nothing major?). Idk the tools used in the front-end and I am 'new' in the area and I work with back-end for now. I am doing a project that has websocket calls, but I need to save them in the collection to be able to make them available to the public. Could you resolve these conflicts or could you give me some direction on what I can do?

kerem commented

2026-03-16 18:33:40 +03:00

Author

Owner

@nosovk commented on GitHub (Mar 18, 2025):

It would be nice to land that, and also to improve real-time tooling.

@nosovk commented on GitHub (Mar 18, 2025): It would be nice to land that, and also to improve real-time tooling.