Closed knolleary closed 9 years ago
Ahh, I was unaware that the HTTP In node supported path parameters, so I had taken path support out of the swagger node until we could discuss it. Will revisit with the new knowledge.
Checked in a change set to address this. The node will convert :petId
to {petId}
. The editor will also pick up that there are path params in the URL, and include them in the swagger doc config dialog. The user can edit the description and type, but cannot edit the name or in fields for these params, and they cannot be removed. Instead, the editor checks the url and adds new path parameters to the doc when needed, and also cleans up old path params that no longer exist.
@lostinthestory can you raise a pull request for this? and for the fix you did for #4
BTW, for future reference, preferred commit message style is:
First line: A short summary of the change
Second line: If it fixes an issue, something like "Fixes #2" or "Closes #2" - Github will automatically close issues when it sees a commit merged with such a statement.
Third line onwards: a longer description if it is needed
Point being, don't reference an issue # in the first line of the commit.
Ah - just saw the PR arrive. Thanks :)
I got the email just as I was submitting the PR. Will keep that in mind with the commit messages. Wasn't sure about auto closing the issues until the changes were merged into master.
The auto-close only occurs when the commit is merged into this repo - ie, when the PR is merged.
Ah, excellent! Good to know! Thanks
An HTTP In node can identify named path parameters using the Express syntax:
The swagger doc node should spot those parameters and automatically add parameter entries for them.
In the generated swagger, the format needs to be transformed to: