Reminds me of https://github.com/alufers/mitmproxy2swagger which I discovered from this thread https://news.ycombinator.com/item?id=31354130 I generated some specs from that! I ran into trouble keeping them up to date.
Show HN: Auto-generate an OpenAPI spec by listening to localhost
11–20 of 78 posts
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#12This is probably cool and useful, but there's no way to know how much of the API you're covering, right? I find that the real shortage of tools exists going the other way: from OpenAPI to code. The ecosystem has proven to be a huge disappointment there, comprising a janky collection of defective tools that still (years later) don't support version 3.1 (a critical update).
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#13Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#14I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#15I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#16I was looking into how this works for inspiration, and it seems like the work of inferring the OpenAPI definition from recorded requests/responses is handled by the har-to-openapi nodejs library [2]. Is this by the same team? If not, kudos for packaging this up in a proxy -- seems like a useful interface into that library.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#17I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)
This seems pretty simple to me to do. Search the html of the main page for anchor tags. Add the links in those tags to an array as your exploration frontier. Once done parsing that html, load the next link. Add deduplication to avoid loops and just run a depth-first search. What am I missing?
You would also have to fill and submit forms with valid and invalid data. You would have to toggle checkboxes, change radio buttons, click buttons, (e.g. "Apply filters" after changing values in a product filter section), and generally go through many combinations of inputs to find all valid parameters and possible responses.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#18Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#19I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)
This seems pretty simple to me to do. Search the html of the main page for anchor tags. Add the links in those tags to an array as your exploration frontier. Once done parsing that html, load the next link. Add deduplication to avoid loops and just run a depth-first search. What am I missing?
For example, clicking a link which loads some data, then clicking edit (which isn't even an anchor), typing in & clicking stuff, then clicking the save button (don't click the cancel button!) would not be an interaction that would get picked up with your suggestion. Detecting loops becomes much more ambiguous and backtracking to get all the permutations of interactions becomes a whole other problem to solve.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#20It is like the TDD approach, design before build.
Writing or generating tests after you build the code, is the same as this. It is guessing what it should do. The OpenAPI specification, and the tests should tell you what it should do, not the code.
If you have the specification, everyone (and also AI) can write the code for you to make it work. But the specification is about what you think it should do. That are the questions and requirements that you have about the system.