Live data from Hacker News

Show HN: Auto-generate an OpenAPI spec by listening to localhost

github.com

11–20 of 78 posts

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#12

This 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).

[deleted]

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#13
A nice tool for research, or for documenting third-party APIs. Let's not forget, though, that one of the goals of OpenAPI is to serve as a design and documentation artifact in design-first API development; generating OpenAPI from code or, as in this case, from network traffic, is an interesting complement and something you can use to test the implementation against the design.

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#14
post #5

I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)

One slightly related thing you can do is to test the API with schemathesis[0]

[0] https://github.com/schemathesis/schemathesis

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#15
post #5

I 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?

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#16
I have a similar need but for the FHIR[1] spec, which has its own way of describing RESTful http endpoints that serve FHIR data.

I 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.

1. https://www.hl7.org/fhir/

2. https://github.com/jonluca/har-to-openapi

Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost

#17
post #5

I 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?

In many web apps there are going to be buttons and links that are not represented as . You would realistically have to enumerate everything that has any kind of event handler attached since it could potentially trigger an API call.

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

#19
post #5

I 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 brochure / static content sites this is definitely the beginnings of a web crawler but it can be a lot trickier for web apps.

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

#20
When you build an API, please start with the OpenAPI specification, before you write any code for your API. It can be iterative, but for every part, just start with the OpenAPI, and think about what you want from the API, what do you want to send, and what to receive.

It 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.

Post reply on HN