openapi-to-postman
openapi-to-postman copied to clipboard
postmanlabs
Request name source option should allow explicit fields, and requires documentation and implementation fix
Documentation says fallback option takes :
Determines how the requests inside the generated collection will be named. If “Fallback” is selected, the request will be named after one of the following schema values: description, operationid, url.
But the code implementation in the utils function has the summary and not description.
case 'fallback' : {
// operationId is usually camelcase or snake case
reqName = operation.summary || utils.insertSpacesInName(operation.operationId) || reqUrl;
break;
}
It would be better to allow users to provide sources as summary, operationID, or URL than doing an or operation.
This is implemented already at the default section but options.RequestNameSource is being resetted to default option before this step so user can't really use it
default : {
reqName = operation[options.requestNameSource];
break;
}
@praveendvd Got the point. Just a question. If we allow either one of summary, oprationID or URL as request name source, what should be name if corresponding property is not present in schema? (let's say operationID is not present in schema and we have provided operationID1 as option)
@VShingala the request is that , instead of using fall back .allow user to choose from the drop down which property to be used for naming .
@ahemed-haneen Current behaviour is the same as what's described in Options while import/generate collection flow.
i.e. Mentioned fields will be used as a fallback in the exact order as mentioned in Option description.
As for the specific request of having option value for each property separately hasn't been worked upon yet.
@praveendvd Got the point. Just a question. If we allow either one of
summary,oprationIDorURLas request name source, what should be name if corresponding property is not present in schema? (let's sayoperationIDis not present in schema and we have providedoperationID1as option)
The default fallback if someone provides a specific property should be the URL. The Path will always be present and the user who wanted to use the property should ensure that it is present on all requests.
In implementations where the OperationId is set appropriately, the OperationId would be the ideal naming convention. Summary can be way too wordy since it is generated from the function summaries, which are usually extensive explanations.
@praveendvd Got the point. Just a question. If we allow either one of
summary,oprationIDorURLas request name source, what should be name if corresponding property is not present in schema? (let's sayoperationIDis not present in schema and we have providedoperationID1as option)The default fallback if someone provides a specific property should be the URL. The Path will always be present and the user who wanted to use the property should ensure that it is present on all requests.
In implementations where the OperationId is set appropriately, the OperationId would be the ideal naming convention. Summary can be way too wordy since it is generated from the function summaries, which are usually extensive explanations.
Couldn't agree more - it would seem to me that a much more appropriate hierarchy for this would be operationId -> summary -> description -> url. Given that, in my case, we provide all of these I'm limited to either an unnecessarily long operation name from the summary or the URL of the request and have no option use the operation IDs in our specifications without doing a list pre-processing to replace summaries with operation IDs which is less than ideal.
If there is no desire to add more flexibility per the OP's request, perhaps we could adjust the hierarchy/order for the "fallback" strategy? Are you accepting PRs for this?
