[GH-ISSUE #29] Ability to store/share/create collections

kerem commented

2026-03-16 12:42:21 +03:00

Owner

Originally created by @curtchan on GitHub (Aug 23, 2019).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/29

Originally assigned to: @TheHollidayInn on GitHub.

I like the idea of your project, but first thing that i noticed that it lacks comparing to postman - shareable/saveable collections

It would require:

ability to group requests into collections (naming requests, naming collections, ordering them)
ability to save collection/read collection (json export/import?, storing in browser storage?)

Originally created by @curtchan on GitHub (Aug 23, 2019). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/29 Originally assigned to: @TheHollidayInn on GitHub. I like the idea of your project, but first thing that i noticed that it lacks comparing to postman - shareable/saveable collections It would require: * ability to group requests into collections (naming requests, naming collections, ordering them) * ability to save collection/read collection (json export/import?, storing in browser storage?)

kerem

2026-03-16 12:42:21 +03:00

closed this issue
added the
help wanted

feature
labels

kerem commented

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

Author

Owner

@keithl8041 commented on GitHub (Aug 23, 2019):

Being able to share collection is the killer feature for Postman and is why they can charge a premium for their team membership. Being able to export/import is a step down from that but still gets you most of the same functionality, without the advantages of being able to sync automatically between team members.

So I'd second the import/export functionality. JSON seems an obvious choice but need to be careful around how it gets serialised to make sure it can work nicely with git (ie: if two or more people edit a file, can git patch it together nicely).

I'd like to help out with this if we can agree a good approach. I think the logical separation of creating the collections and the import/export makes sense. How best to proceed?

@keithl8041 commented on GitHub (Aug 23, 2019): Being able to share collection is the killer feature for Postman and is why they can charge a premium for their team membership. Being able to export/import is a step down from that but still gets you most of the same functionality, without the advantages of being able to sync automatically between team members. So I'd second the import/export functionality. JSON seems an obvious choice but need to be careful around how it gets serialised to make sure it can work nicely with git (ie: if two or more people edit a file, can git patch it together nicely). I'd like to help out with this if we can agree a good approach. I think the logical separation of creating the collections and the import/export makes sense. How best to proceed?

kerem commented

2026-03-16 12:42:43 +03:00

Author

Owner

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

Thumbs up! This feature would make Postwoman top of its class. Looking forward on collaborating with you.

@liyasthomas commented on GitHub (Aug 23, 2019): Thumbs up! This feature would make Postwoman top of its class. Looking forward on collaborating with you.

kerem commented

2026-03-16 12:42:48 +03:00

Author

Owner

@keithl8041 commented on GitHub (Aug 23, 2019):

The sync operation is possibly covered by #26 where using Firebase to sync data is mentioned, so potentially this ticket should just be about creating the collection organisation and management concept.

@keithl8041 commented on GitHub (Aug 23, 2019): The sync operation is possibly covered by #26 where using Firebase to sync data is mentioned, so potentially this ticket should just be about creating the collection organisation and management concept.

kerem commented

2026-03-16 12:42:53 +03:00

Author

Owner

@andrewyoung918 commented on GitHub (Aug 23, 2019):

I like the idea of a work space tab filing the need of collections.

I think being able to import / export openAPI docs as a tab, and persisting tabs in browser storage would be great, not require auth or db server.

An alternative to having cross team synced connections would be a "Share tab on slack" that posted a link that includes a serialized export.

Would make sharing super straight forward. Would serve many teams needs better than postman. It won't solve for late Enterprise, but I don't think this tool needs to.

@andrewyoung918 commented on GitHub (Aug 23, 2019): I like the idea of a work space tab filing the need of collections. I think being able to import / export openAPI docs as a tab, and persisting tabs in browser storage would be great, not require auth or db server. An alternative to having cross team synced connections would be a "Share tab on slack" that posted a link that includes a serialized export. Would make sharing super straight forward. Would serve many teams needs better than postman. It won't solve for late Enterprise, but I don't think this tool needs to.

kerem commented

2026-03-16 12:42:58 +03:00

Author

Owner

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

This approach could be implemented straight away. Can you take the initiative and consider making a PR. All supporters will have your back.

@liyasthomas commented on GitHub (Aug 24, 2019): This approach could be implemented straight away. Can you take the initiative and consider making a PR. All supporters will have your back.

kerem commented

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

Author

Owner

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

Related to #5
I'd like to see yaml used for the format.
Perhaps using fetch terminology would be good: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Supplying_request_options
Another option is to use har (har is a format provided by browser exports)

@jgroom33 commented on GitHub (Aug 25, 2019): Related to #5 I'd like to see yaml used for the format. Perhaps using fetch terminology would be good: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#Supplying_request_options Another option is to use har (har is a format provided by browser exports)

kerem commented

2026-03-16 12:43:08 +03:00

Author

Owner

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

Example:

name: nocall
  var:
    foo: 1
name: fetch1
  request:
    url: http://foo.bar
    method: POST
    body:
      foo: {{ nocall.foo }}
name: fetch2
  request:
    url: http://foo.bar/{{ fetch1.response.id }}
    method: GET
  until: {{ fetch2.response.status }} == 200
  delay: 1
  repeat: 30

@jgroom33 commented on GitHub (Aug 25, 2019): Example: ```yaml name: nocall var: foo: 1 name: fetch1 request: url: http://foo.bar method: POST body: foo: {{ nocall.foo }} name: fetch2 request: url: http://foo.bar/{{ fetch1.response.id }} method: GET until: {{ fetch2.response.status }} == 200 delay: 1 repeat: 30 ```

kerem commented

2026-03-16 12:43:13 +03:00

Author

Owner

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

Could we not use JSON instead? Even if it's simply mapping the same structure from YAML to JSON?

@NBTX commented on GitHub (Aug 25, 2019): Could we not use JSON instead? Even if it's simply mapping the same structure from YAML to JSON?

kerem commented

2026-03-16 12:43:18 +03:00

Author

Owner

@fishnal commented on GitHub (Aug 25, 2019):

I too am a bit lost on why yaml is preferred. Could we use JSON as the standard for passing the data around and maybe offer options to download/export (and potentially edit) in yaml?

@fishnal commented on GitHub (Aug 25, 2019): I too am a bit lost on why yaml is preferred. Could we use JSON as the standard for passing the data around and maybe offer options to download/export (and potentially edit) in yaml?

kerem commented

2026-03-16 12:43:23 +03:00

Author

Owner

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

Yaml is easier to read.
Yaml also provides include functionality. This would assist with multi-file collections.
Postman does this with an overloaded json file that includes directories and subdirectories.
Yaml + includes would accomplish the same by using using the filesystem + directories for organization.

@jgroom33 commented on GitHub (Aug 25, 2019): Yaml is easier to read. Yaml also provides `include` functionality. This would assist with multi-file collections. Postman does this with an overloaded json file that includes directories and subdirectories. Yaml + `includes` would accomplish the same by using using the filesystem + directories for organization.

kerem commented

2026-03-16 12:43:28 +03:00

Author

Owner

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

I'm not seeing any evidence that an include functionality does exist in YAML.
https://stackoverflow.com/a/15437697/2872279

Even so, it would be more than possible to implement this in JSON.
In any case, my two most favorable alternatives are:

Using JSON5, a superset of JSON that, amongst other things, allows marking up JSON with comments. https://json5.org/
Simply using JavaScript files - and perhaps exposing some helper functions.

@NBTX commented on GitHub (Aug 25, 2019): I'm not seeing any evidence that an `include` functionality does exist in YAML. https://stackoverflow.com/a/15437697/2872279 Even so, it would be more than possible to implement this in JSON. In any case, my two most favorable alternatives are: 1. Using JSON5, a superset of JSON that, amongst other things, allows marking up JSON with comments. https://json5.org/ 2. Simply using JavaScript files - and perhaps exposing some helper functions.

kerem commented

2026-03-16 12:43:34 +03:00

Author

Owner

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

Another thing to note, is that you seem to be favoring writing these by hand?
I think the direction this issue is going in, is that these would be generated and read by the application only.

@NBTX commented on GitHub (Aug 25, 2019): Another thing to note, is that you seem to be favoring writing these by hand? I think the direction this issue is going in, is that these would be generated and read by the application only.

kerem commented

2026-03-16 12:43:39 +03:00

Author

Owner

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

What I see is.. JSON stand as a solid option since it is faster and probably still interoperable with more systems. If i take readability concerns, YAML shines.

But I had to stick to JSON since we're doing it in JS.

@liyasthomas commented on GitHub (Aug 25, 2019): What I see is.. JSON stand as a solid option since it is faster and probably still interoperable with more systems. If i take readability concerns, YAML shines. But I had to stick to JSON since we're doing it in JS.

kerem commented

2026-03-16 12:43:44 +03:00

Author

Owner

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

Thanks for the correction on yaml. It does not seem to include include. :) It is only a convention.

@jgroom33 commented on GitHub (Aug 26, 2019): Thanks for the correction on yaml. It does not seem to include `include`. :) It is only a convention.

kerem commented

2026-03-16 12:43:49 +03:00

Author

Owner

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

Do you have an example of what a stored collection would look like? What should the schema be? (har, fetch, something else)

@jgroom33 commented on GitHub (Aug 26, 2019): Do you have an example of what a stored collection would look like? What should the schema be? (har, fetch, something else)

kerem commented

2026-03-16 12:43:54 +03:00

Author

Owner

@TheHollidayInn commented on GitHub (Sep 28, 2019):

Can I work on the issue of creating and storing the collections?

@TheHollidayInn commented on GitHub (Sep 28, 2019): Can I work on the issue of creating and storing the collections?

kerem commented

2026-03-16 12:43:59 +03:00

Author

Owner

@jgroom33 commented on GitHub (Sep 28, 2019):

@NBTX
Yes, I'm in favor of providing the power of writing these tests by hand.
I see this project progressing as follows:

Store collections
Execute stored collections via CLI tool (for CI integration)

A critical weakness of postman is that a stored collection is basically a binary file. The UI is required for any modifications to be implemented.
This makes code review for any postman collections committed to a repository cumbersome.

This is my experience with postman:

Woohoo. A UI tool that can execute rest without coding
Ugh. I need to write code just to do trivial things like access responses from a previous call
Woohoo. I can use Newman to run these stored collections
Ugh. We need a yearly license to share these collections as a team.
Hmmm. Let's just commit the collections to a repo
Ugh. These collections are terrible to update because a UI is required.
Hmmm. What other frameworks are available?

Will postwoman become the framework that is a great UI and is CI and code review friendly?

@jgroom33 commented on GitHub (Sep 28, 2019): @NBTX Yes, I'm in favor of providing the power of writing these tests by hand. I see this project progressing as follows: 1. Store collections 2. Execute stored collections via CLI tool (for CI integration) A critical weakness of postman is that a stored collection is basically a binary file. The UI is required for any modifications to be implemented. This makes code review for any postman collections committed to a repository cumbersome. This is my experience with postman: 1. Woohoo. A UI tool that can execute rest without coding 2. Ugh. I need to write code just to do trivial things like access responses from a previous call 3. Woohoo. I can use Newman to run these stored collections 4. Ugh. We need a yearly license to share these collections as a team. 5. Hmmm. Let's just commit the collections to a repo 6. Ugh. These collections are terrible to update because a UI is required. 7. Hmmm. What other frameworks are available? Will postwoman become the framework that is a great UI and is CI and code review friendly?

kerem commented

2026-03-16 12:44:04 +03:00

Author

Owner

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

@TheHollidayInn you are free to work on this 🎉 Assigning to you. You're good to go!

@liyasthomas commented on GitHub (Sep 28, 2019): @TheHollidayInn you are free to work on this :tada: Assigning to you. You're good to go!

kerem commented

2026-03-16 12:44:09 +03:00

Author

Owner

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

@jgroom33 it's only been ~a month since the first commit and this project has gained so much of traction within this short span of time! It's exciting to know that people/devs are really making use of this platform in their daily workflow. Now we've great community and I'm sure we could make this, the best tool for API resting.

@liyasthomas commented on GitHub (Sep 28, 2019): @jgroom33 it's only been ~a month since the first commit and this project has gained so much of traction within this short span of time! It's exciting to know that people/devs are really making use of this platform in their daily workflow. Now we've great community and I'm sure we could make this, the best tool for API resting.

kerem commented

2026-03-16 12:44:14 +03:00

Author

Owner

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

I'll post my progress today to get feedback, and ensure I'm working on the features requests :D.

@TheHollidayInn commented on GitHub (Oct 1, 2019): I'll post my progress today to get feedback, and ensure I'm working on the features requests :D.

kerem commented

2026-03-16 12:44:19 +03:00

Author

Owner

@jgroom33 commented on GitHub (Oct 7, 2019):

It would be great if the collection storage could also leverage the server directory structure. This would allow the execution ordering to be controlled by alphanumeric file naming.

@jgroom33 commented on GitHub (Oct 7, 2019): It would be great if the collection storage could also leverage the server directory structure. This would allow the execution ordering to be controlled by alphanumeric file naming.

kerem commented

2026-03-16 12:44:24 +03:00

Author

Owner

@jgroom33 commented on GitHub (Oct 8, 2019):

I think the default behavior should be filesystem storage.
The config should allow an array of directories to be specified for loading. In this scenario, a directory is equivalent to a postman collection.

This will allow a future feature: git tracking each collection directly from postwoman UI

@jgroom33 commented on GitHub (Oct 8, 2019): I think the default behavior should be filesystem storage. The config should allow an array of directories to be specified for loading. In this scenario, a directory is equivalent to a postman collection. This will allow a future feature: git tracking each collection directly from postwoman UI

kerem commented

2026-03-16 12:44:30 +03:00

Author

Owner

@OGProgrammer commented on GitHub (Oct 8, 2019):

openAPI support would be huge, looking for that as I see no way of saving/exporting a config

@OGProgrammer commented on GitHub (Oct 8, 2019): openAPI support would be huge, looking for that as I see no way of saving/exporting a config

kerem commented

2026-03-16 12:44:35 +03:00

Author

Owner

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

Export/import request collections with OpenAPI support would tremendously elevate this project to the next level.

@liyasthomas commented on GitHub (Oct 8, 2019): Export/import request collections with OpenAPI support would tremendously elevate this project to the next level.

kerem commented

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

Author

Owner

@jgroom33 commented on GitHub (Oct 8, 2019):

OpenAPI is a spec to define an API. It is not a model or schema for a singular execution or collection of executions.

For example, assume a collection stores 2 requests that call the same API uri. OAI is not designed to define an API twice. Additionally, OAI works by defining a schema for request and response. Postwoman and postman only deal with the data. There is no spec in OAI to define the actual data, only the schema of the data.

So, I don't think OAI could provide any value to this specific issue (collection storage)

If there is a goal to import an OAI spec into postwoman (as postman does) it should be a separate issue.

@jgroom33 commented on GitHub (Oct 8, 2019): OpenAPI is a spec to define an API. It is not a model or schema for a singular execution or collection of executions. For example, assume a collection stores 2 requests that call the same API uri. OAI is not designed to define an API twice. Additionally, OAI works by defining a schema for request and response. Postwoman and postman only deal with the data. There is no spec in OAI to define the actual data, only the schema of the data. So, I don't think OAI could provide any value to this specific issue (collection storage) If there is a goal to import an OAI spec into postwoman (as postman does) it should be a separate issue.

kerem commented

2026-03-16 12:44:45 +03:00

Author

Owner

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

We'll go with seperate issue then.

@liyasthomas commented on GitHub (Oct 8, 2019): We'll go with seperate issue then.

kerem referenced this issue

2026-03-17 00:21:41 +03:00

[PR #525] [CLOSED] Add nl-BE translation #2680

kerem referenced this issue

2026-03-17 00:59:37 +03:00