Click on a path parameter merge broken?
Hey hey. Thanks for this amazing extension! On first sight it works very well. Only when I click on a path parameter it merges too much of path into one. Example:
/api/v2/faq_entries/340/feedback
/api/v2/faq_entries/340/recommended_faqs
/api/v2/faq_entries/340/related_faqs
clicking on 340 results in:
/api/v2/faq_entries/:param3/feedback
Although I'd expect:
/api/v2/faq_entries/:param3/feedback
/api/v2/faq_entries/:param3/recommended_faqs
/api/v2/faq_entries/:param3/related_faqs
Any idea what's the issue here? Thanks a lot!
btw. why param3 and not starting at least at param1? :)
ah the param name param3 is derived from depth of the path /param0 vs /api/param1. I'd expect it's derived from the click - first merge click param1, sencond param2.
@rngtng gotcha, this is working as expected but the UX is wonky. Have addressed this in a tool that is to OpenAPI DevTools was to at-your-service.
It is indeed based on depth. Please feel free to re-raise if I've misread you.
hey @AndrewWalsh thanks for you fast quick reply.
Have addressed this in a tool that is to OpenAPI DevTools was to at-your-service.
I don't understand you here - What do you mean with this?
Btw. I checked again, for me it's not just the UX, but even in the export the original routes are missing. So instead of
/api/v2/faq_entries/:param3/feedback
/api/v2/faq_entries/:param3/recommended_faqs
/api/v2/faq_entries/:param3/related_faqs
I still get only /api/v2/faq_entries/:param3/feedback in the export (same as UI). So I still think it's a bug...
Hey @rngtng
But that is the expected output. You've set the 4th parameter of the URL as a path parameter. So it will collapse to api/v2/faq_entries/:param3/feedback, no?
Well for feedback yes. But why are recommended_faqs and related_faqs gone? I'd expect them to exist as:
/api/v2/faq_entries/:param3/recommended_faqs /api/v2/faq_entries/:param3/related_faqs
Ah I see what you mean - my mistake, overlooked this. Thanks for raising this and pointing out the obvious mishap here.
I've now acknowledged this issue, addressed where possible on a possibly indefinite timeline.
Great. Thanks
I have in mind a CLI tool now to supercede this to autogenerate OpenAPI 3.1 or 4.0 specifications for any API, so I'm not looking to improve this approach further unless there is significant demand, apologies!