Handle free form query parameters
See original GitHub issueDescribe the bug Given an OpenAPI 3 yaml file with a free-form query parameter, for example:
openapi: "3.0.0"
...
paths:
/users:
post:
parameters:
- name: userParameters
in: query
schema:
type: object
addtionalProperties:
type: string
style: form
...
when generating the postman spec file, then a query parameter (named “userParameters” from the example) is created into the output Postman spec file.
Steps to Reproduce
- Create an OpenAPI 3 yaml spec with a free-form query parameter
- Generate the Postman spec file
- Import the generated spec into Postman
Postman will insert the free-form query parameter as query parameter, and it will show the free-form query parameter name into the URL.
Expected behavior
- Postman should not show the free-form query parameter name into the URL.
App information (please complete the following information):
- Postman version: 7.1.1
Additional context
A possible solution could be to remove the free-form query parameter from the generated postman spec file, for example updating the util.js getParametersForPathItem
method as follows:
/**
* Create parameters specific for a request
* @param {*} localParams parameters array
* @returns {Object} with three arrays of query, header and path as keys.
* @no-unit-test
*/
getParametersForPathItem: function(localParams) {
var tempParam,
params = {
query: [],
header: [],
path: []
};
_.forEach(localParams, (param) => {
tempParam = param;
if ((tempParam.in === 'query') && (this.isFreeFormQueryParameter(param) == false)) {
params.query.push(tempParam);
}
else if (tempParam.in === 'header') {
params.header.push(tempParam);
}
else if (tempParam.in === 'path') {
params.path.push(tempParam);
}
});
return params;
},
/**
* Check if the query parameter is a free-form query parameter
* @param {*} parameter query parameter
* @returns {Boolean} true if the parameter is a free-form query parameter.
*/
isFreeFormQueryParameter: function(parameter) {
return (parameter.schema !== undefined) && (parameter.schema.addtionalProperties !== undefined) && (parameter.schema.addtionalProperties instanceof Object) && (parameter.schema.style === 'form');
},
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Handling freeform GET URL parameters in Play 2 routing
Something like this should work: GET /foo controllers.MyController.foo(name: String ?= "", age: Int ?= 0). Since your parameters can be left ...
Read more >Use parameters in queries, forms, and reports
This article explains how to use forms in Access to enhance your use of parameters in queries, forms, and reports.
Read more >A Beginner's Guide to URL Parameters - SEMrush
In this comprehensive guide, we explore the ins and outs of URL parameters. Discover now how to use query strings without hurting your ......
Read more >Parameter Serialization - Swagger
This corresponds to collectionFormat: multi from OpenAPI 2.0. Given the path /users with a query parameter id , the query string is serialized...
Read more >Parameters | Query and analyze data - Mode Support
A text parameter presents the report viewer with a free-form text box that ... SQL query to handle an empty Text parameter input...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@marcoMobilab Yes, we have added support for serialization while conversion, this means all OAS defined styles are supported in params. For the definition provided by you mentioned behavior will be followed and For the given example try importing the below schema which should result in the mentioned behavior by you. (Make sure to use
Example
as value forRequest parameter resolution
option underAdvanced Options
)@VShingala with the second point I meant to say that the free-form query parameter could be a complex JSON object with arrays. But this is an optional feature, the main feature instead is to have the simple key-value free form parameters correctly handled. Take the following as an example:
Parameters of the POST request to the “/users” endpoint: firstName: Henry, lastName: Lee, userParameters: {“age”: “28”, “weight”: “78”}
POST request to the “/users” endpoint: POST /users?firstName=Henry&lastName=Lee&age=28&weight=78