mandrean/postman-collection-rs

A Postman Collection serialization & deserialization library, written in Rust.

postman-collection-rs

Postman Collection serialization & deserialization library, written in Rust.

Install

Add the following to your Cargo.toml file:

[dependencies]
postman_collection = "0.1"

Use

extern crate postman_collection;

fn main() {
  match postman_collection::from_path("path/to/postman-collection.json") {
    Ok(spec) => println!("spec: {:?}", spec),
    Err(err) => println!("error: {}", err)
  }
}

See examples/printer.rs for more.

Contribute

This project follows semver, conventional commits and semantic releasing using semantic-rs.

Note

Inspired by softprops/openapi.

postman-collection-rs's Issues

API key auth is not supported

A collection with API key auth set (on a collection or endpoint) will fail to parse with an error message of

data did not match any variant of untagged enum PostmanCollection.

An example of API key auth looks like

"auth": {
            "type": "apikey",
            "apikey": [
                {
                    "key": "value",
                    "value": "bar",
                    "type": "string"
                },
                {
                    "key": "key",
                    "value": "foo",
                    "type": "string"
                }
            ]
        },

Currently AuthType does not contain an entry for apikey, nor Auth

Example request

postman collection 2.1.0 desserealization error

Hello,

I am using your library to convert some postman collections.

First of all, thanks for the great work.

I have found what seems to be an error when defining enums to represent form data for 2.1.0 collections.

First of all, I am trying to load the collection at https://www.zoho.com/sites/default/files/writer/writer-api-collection.json

This file has validated successfully against the JSON schema it declares, using https://www.jsonschemavalidator.net/ so that we know the collection itself is not invalid.

When I run your library, it says that None of the pre defined variants to represent known postman schemas matched the JSON, and exits with an error.

But by inspecting the collection header I know that this follows the 2.1.0 schema version, so I isolated this variant and tried again.

This time, the desserealizer complained about failing to parse item[0].item[0].item[0] because no variant of the RequestUnion enum could be matched.

I inspected then the first request of the json file and matched by hand all fields, when I found the error:

All request fields desserealized successfully with the exception of the body field.

For reference, I am pasting the body field which failed below before going forward:

"body": {
    "mode": "formdata",
    "formdata": [
        {
            "key": "content",
            "description": "Mandatory - {File} - Provide the required content in your API request body.",
            "type": "file",
            "src": []
        },
        {
            "key": "filename",
            "value": "Resume",
            "description": "Mandatory - {String} Provide the filename to create document in this name. ",
            "type": "text"
        },
        {
            "key": "folder_id",
            "value": "egrjadd41d336806742cfa45a61528bb0210d",
            "description": "Optional - { String } Provide the folder id of the folder to where the document to be created.",
            "type": "text"
        }
    ]
}

The Postman JSON schema specifies that a request body can have some modes:

• raw
• urlencoded
• formdata
• file
• graphql

This uses formdata as its body mode.

a formData is an array of items of type formParameter.

The formParameter object can follow, accordingly to the schema, two variantes (see line 688 of schema definition or the documentation at https://schema.postman.com/collection/json/v2.1.0/draft-07/docs/index.html.

Here, your implementation deviates from the schema, because the FormParameter is defined as a struct instead of as an enum containing these ttwo possible variants.

Although I understand why that choice was done and the strategy to deal with possible variants, the related bug happens right here:
The source field of FormParameter struct is described as pub src: Option, but this doesn't cover all schema variants. In fact, if you look at the request body I pasted above, you will notice that the src field is defined as an empty array, which is perfectly acceptable in the second variation in the schema (see line 723 of the schema) or schema documentation.

By querying the docs, I haven't been able to determine what is accepted in this array, but it is a valid statement and it does appear on postman generated collections.

I suppose the most ovbious choice here would be to make this an enum containing either a String or a vec of Strings and, in fact, this kind of works for me.

...
pub src: Option<FormParameterSrcUnion>,
}

#[serde(untagged)]
#[derive(Clone, Debug, Deserialize, Serialize, PartialEq)]
pub enum FormParameterSrcUnion {
    File(String),
    Files(Vec<String>),
}

With this change, I have been able fo fully parse the aforementioned collection.