-
Notifications
You must be signed in to change notification settings - Fork 88
Closed
Description
Swagger supports parameters that are defined on path-level, i.e., are used for all operations on that path, see https://swagger.io/specification/v2/#path-item-object.
These show up next to operations (as parameters
attribute) in the definition json, which also works as a Minimal Working Example
{
"swagger": "2.0",
"basePath": "/",
"paths": {
"/example/{pathTemplateParam}": {
"parameters": [{
"description": "A path parameter, used for path templating.",
"name": "pathTemplateParam",
"in": "path",
"required": true,
"type": "integer"
}],
"get": {
"responses": {
"200": {"description": "Success"}
},
"description": "Example operation",
"operationId": "example_operation",
"parameters": [],
"tags": ["example"]
}
}
},
"info": {
"title": "Example swagger 2.0 doc",
"version": "1.0"
},
"produces": [
"application/json"
],
"consumes": [
"application/json"
]
}
Currently, "parameters" on the path object is interpreted as operation and not parsed, leading to the following generated code:
export class ExampleService {
/**
*
*/
static example(options: IRequestOptions = {}): Promise<any> {
return new Promise((resolve, reject) => {
let url = basePath + '/example/{pathTemplateParam}';
const configs: IRequestConfig = getConfigs('get', 'application/json', url, options);
axios(configs, resolve, reject);
});
}
}
Notice, how pathTemplateParam
is not replaced. My changes will parse path-level parameters if present, leading to generated code, which replaces the parameter properly.
export class ExampleService {
/**
*
*/
static example(
params: {
/** A path parameter, used for path templating. */
pathTemplateParam: number;
} = {} as any,
options: IRequestOptions = {}
): Promise<any> {
return new Promise((resolve, reject) => {
let url = basePath + '/example/{pathTemplateParam}';
url = url.replace('{pathTemplateParam}', params['pathTemplateParam'] + '');
const configs: IRequestConfig = getConfigs('get', 'application/json', url, options);
axios(configs, resolve, reject);
});
}
}
Let me know, if I can provide additional info.
Activity
[-]Fix: Support for path level parameters[/-][+]Support for path level parameters[/+]Manweill commentedon Mar 14, 2025
path params is work good.
Manweill commentedon Mar 14, 2025
you can see it in example
JulianNeuberger commentedon Mar 15, 2025
This is true for parameters that are in the
operation
object, e.g.;it is not true for my example above. Please see the link to the Swagger specs I provided, the library currently does not treat a
parameters
object on the same level as operations likeget
,post
etc. Try my example in codegen - it will not produce the replace statement you have shown in your example.Manweill commentedon Mar 18, 2025
add in swagger.json
and generated
JulianNeuberger commentedon Mar 18, 2025
I can't add that to my swagger.json, it is generated. And I don't think I should have to add it, the swagger.json I provided in my example is valid according to the specs. I think swagger-axios-codegen would benefit from being able to parse such valid specs.
From https://swagger.io/specification/v2/#path-item-object:
If you do not want to parse parameters on this level, I am fine with that as well, even though I honestly do not fully understand your reasons.
Manweill commentedon Mar 18, 2025
it mean, i add your example in swagger.json spec, and then use codegen function to build. the image was result.
I welcome any reasonable PRs to merge into this repository.
I'm just using the toolbelt example to show you that your problem is already implemented in codegen and runs successfully, and that you need to provide me with a reproduction of the example.
As you can see, testing the your example swagger spec by adding it to swagger.json in repo example , it work well.
Manweill commentedon Mar 18, 2025
I think I guess what you mean. the parameters does not in operation method level ? Typically, in a real spec, no parameters are generated in this location; all parameters are inside the operation.
JulianNeuberger commentedon Mar 18, 2025
Exactly! Not sure what you mean by "real spec", the specification for swagger v2 states that parameters can be on this level, and for example Flask RESTX will generate a swagger.json like the one I showed (which is why I can't / won't change my spec, it is generated by RESTX).
I already opened a PR #207 , let me know if you need any changes.
Manweill commentedon Mar 19, 2025
Cool. Already merged