Ability to store/share/create collections

[curtchan]

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?)

[keithl8041]

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?

[liyasthomas]

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

[keithl8041]

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.

[andrewyoung918]

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.

[liyasthomas]

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

[jgroom33]

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]

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

[NBTX]

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

[fishnal]

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?

[jgroom33]

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.

[NBTX]

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.

[NBTX]

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.

[liyasthomas]

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.

[jgroom33]

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

[jgroom33]

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

[TheHollidayInn]

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

[jgroom33]

@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?

[liyasthomas]

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

[liyasthomas]

@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.

[TheHollidayInn]

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

[jgroom33]

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]

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

[OGProgrammer]

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

[liyasthomas]

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

[jgroom33]

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.

[liyasthomas]

We'll go with seperate issue then.