starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 16:55:59 +03:00

[GH-ISSUE #4] Serialize a request into JSON? #3

New issue

Closed

opened 2026-03-16 12:40:31 +03:00 by kerem · 10 comments

kerem commented

2026-03-16 12:40:31 +03:00

Owner

Originally created by @banezaklan on GitHub (Aug 22, 2019).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4

Hey there, have you already planned for serializing entire request into JSON? I'm looking for a simple way to document a REST API, and make it "interactable" in the same time.
Like postman has these "Collections" but simpler I think...

Originally created by @banezaklan on GitHub (Aug 22, 2019). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4 Hey there, have you already planned for serializing entire request into JSON? I'm looking for a simple way to document a REST API, and make it "interactable" in the same time. Like postman has these "Collections" but simpler I think...

kerem

2026-03-16 12:40:31 +03:00

closed this issue
added the
help wanted

feature

good first issue
labels

kerem commented

2026-03-16 12:40:52 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Aug 22, 2019):

Hey....

That seems dope, I will work on a PR for that...

But can you clarify what you want ?

Do you want the ability to export the entire request config for a single request or for multiple requests ?

@AndrewBastin commented on GitHub (Aug 22, 2019): Hey.... That seems dope, I will work on a PR for that... But can you clarify what you want ? Do you want the ability to export the entire request config for a single request or for multiple requests ?

kerem commented

2026-03-16 12:40:57 +03:00

Author

Owner

@brandonros commented on GitHub (Aug 28, 2019):

One idea is to store some state in the hash or query string of the URL, which would make sharing a request with other teammates a simple copy + paste away.

@brandonros commented on GitHub (Aug 28, 2019): One idea is to store some state in the hash or query string of the URL, which would make sharing a request with other teammates a simple copy + paste away.

kerem commented

2026-03-16 12:41:02 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Aug 28, 2019):

@brandonros I like this suggestion, can you open this as a separate issue ?

I will start working on the PR.

@AndrewBastin commented on GitHub (Aug 28, 2019): @brandonros I like this suggestion, can you open this as a separate issue ? I will start working on the PR.

kerem commented

2026-03-16 12:41:07 +03:00

Author

Owner

@NBTX commented on GitHub (Aug 28, 2019):

The problem with that though is that the state would, for some more advanced queries be massive.

@NBTX commented on GitHub (Aug 28, 2019): The problem with that though is that the state would, for some more advanced queries be massive.

kerem commented

2026-03-16 12:41:12 +03:00

Author

Owner

@AndrewBastin commented on GitHub (Aug 28, 2019):

The problem with that though is that the state would, for some more advanced queries be massive.

We can introduce support for basic queries only (ie method, url, path) for now.

I think that would still be pretty helpful.

We could flush it out as we go...

@AndrewBastin commented on GitHub (Aug 28, 2019): > The problem with that though is that the state would, for some more advanced queries be massive. We can introduce support for basic queries only (ie method, url, path) for now. I think that would still be pretty helpful. We could flush it out as we go...

kerem commented

2026-03-16 12:41:17 +03:00

Author

Owner

@liyasthomas commented on GitHub (Aug 28, 2019):

Appending on hash or query string of the URL is the easiest way to do this, but in a long run, this would be painful. But as @brandonros said, this could be the easiest way to sahe it to others with copy/paste. #72 does the same approach.

Alternate option is export and import JSON. Which solves the case of complex or large queries but need further dependencies I suppose.

@liyasthomas commented on GitHub (Aug 28, 2019): Appending on hash or query string of the URL is the easiest way to do this, but in a long run, this would be painful. But as @brandonros said, this could be the easiest way to sahe it to others with copy/paste. #72 does the same approach. Alternate option is export and import JSON. Which solves the case of complex or large queries but need further dependencies I suppose.

kerem commented

2026-03-16 12:41:22 +03:00

Author

Owner

@brandonros commented on GitHub (Aug 28, 2019):

We can introduce support for basic queries only (ie method, url, path) for now.

I'd argue for including headers too because of how important they are for authentication and how potentially useless requests are if you can't pass auth headers, etc. :)

I'd imagine you would only start running into grossness when you pass probably, the 16kb - 64kb range? Everything below that is probably fine.

https://postwoman.foo/?state={"model":{ ... }} or hash, if you prefer

@brandonros commented on GitHub (Aug 28, 2019): > We can introduce support for basic queries only (ie method, url, path) for now. I'd argue for including headers too because of how important they are for authentication and how potentially useless requests are if you can't pass auth headers, etc. :) I'd imagine you would only start running into grossness when you pass probably, the 16kb - 64kb range? Everything below that is probably fine. `https://postwoman.foo/?state={"model":{ ... }}` or hash, if you prefer

kerem commented

2026-03-16 12:41:27 +03:00

Author

Owner

@jgroom33 commented on GitHub (Aug 30, 2019):

postman uses the concept of environment to store state. this works ok, but is limited because it is a string by default.
the cache should be a combination of responses, requests, and user defined vars
The UI should present each of these objects.
To reference any of these objects, a templating engine should be implemented. This would allow the following behavior:

define a var of: foo={"model":{"foo":"bar"}}
use var in a request: https://postwoman.foo/?state={{foo}}
use response in subsequent request: https://postwoman.foo/blog/{{request1label.response.items[0].id}}

@jgroom33 commented on GitHub (Aug 30, 2019): postman uses the concept of environment to store state. this works ok, but is limited because it is a string by default. the cache should be a combination of responses, requests, and user defined vars The UI should present each of these objects. To reference any of these objects, a templating engine should be implemented. This would allow the following behavior: 1. define a var of: foo={"model":{"foo":"bar"}} 2. use var in a request: https://postwoman.foo/?state={{foo}} 3. use response in subsequent request: https://postwoman.foo/blog/{{request1label.response.items[0].id}}

kerem commented

2026-03-16 12:41:33 +03:00

Author

Owner

@TheHollidayInn commented on GitHub (Oct 22, 2019):

I think that with my new collections PR, I could solve this issue since the requests are stored in vuex now. I could add a copy button to the requests that are saved and allow the user to get the json

@TheHollidayInn commented on GitHub (Oct 22, 2019): I think that with my new collections PR, I could solve this issue since the requests are stored in vuex now. I could add a copy button to the requests that are saved and allow the user to get the json

kerem commented

2026-03-16 12:41:38 +03:00

Author

Owner

@liyasthomas commented on GitHub (Oct 24, 2019):

#176 #209 fixes this. Hence closing.

@liyasthomas commented on GitHub (Oct 24, 2019): #176 #209 fixes this. Hence closing.

kerem referenced this issue

2026-03-17 00:04:09 +03:00

[PR #3] [MERGED] History is persisted in local storage #2360

kerem referenced this issue

2026-03-17 00:08:35 +03:00