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).
Show HN: Auto-generate an OpenAPI spec by listening to localhost
21–30 of 78 posts
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#22Reminds 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.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#23Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#24A 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
#25When 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 sho…
I've been using a tool to generate OpenApi from code, and am pretty happy with that workflow. Even if writing the API before logic, I'd much rather write the types and endpoints in a real programming language, and just have a `todo` in the body.
You can still write API-driven code without literally writing OpenApi first.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#26When 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 sho…
In that initial implementation period, it's more time-consuming to have to update a spec nobody uses. Maintaining specs separately from your actual code is also a great way to get into situations where your map != your territory.
I'd instead ask: support and use API frameworks that allow you to automatically generate OpenAPI specs, or make a lot of noise to get frameworks that don't support generating specs to support that feature. Don't try to maintain OpenAPI specs without automation :)
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#27When 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 sho…
Example: I used to work at a place that had a massive PHP monolith, developed by hundreds of devs over the course of a decade, and it was the worst pile of hacky spaghetti code I’ve ever seen. Unsurprisingly, it had no API spec. We were later doing tonnes of work to clean it up, which included plans to add an API spec, and switch to a spec-first design process (which we were already doing in services split from the monolith), but there was a massive existing surface area to spec out first. A tool like this would’ve been useful to get a first draft of the API spec up and running quickly for this huge legacy backend.
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#28When 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 sho…
@Path("/people")
public class PeopleApi {
@Path("{personId}")
@GET
public Person getPerson(@PathParam("personId") int personId) {
return db.getPerson(personId);
}
}
It's easy to generate a spec for a JAX-RS class because it has the paths, parameters, types, etc. right there. There's a GET at /people/{personId} which returns a Person and takes a path parameter personId which is an integer.If we're talking about a Go handler which doesn't have that information easily accessible, I understand wanting to start with a spec:
func GetPerson(w http.ResponseWriter, r *http.Request) {
personId, _ := strconv.Atoi(r.URL.Path.something)
person := db.GetPerson(personId)
w.Write(json.marshal(person))
}
func GetPerson(c echo.Context) error { //or with something like Echo/Gin
id := c.Param("id")
person := db.GetPerson(id)
return c.Json(http.StatusOK, person)
}
In Go's case, there's nothing which can tell me what the method takes as input without being able to reason about the whole method. With JAX-RS, it's easy reflect on the method signature and see what it takes as input and what it gives back, but that's not available with Go (with the Go tools that most people are using).This isn't meant as a Go/Java debate, but more a question of whether some languages/frameworks basically already give you the spec you need to the point where you can easily generate an OpenAPI spec from the method definition. Part of that is that the language has types and part of it is the way JAX-RS does things such that things you're grabbing from the request become method parameters before the method is called rather than the method just taking a request object.
JAX-RS makes you define what you want to send and what you want to receive in the method signature. I totally agree that people should start with thinking about what they want from an API, what to send, and what to receive. But is starting with OpenAPI something that would be making up for languages/frameworks that don't do development in that way naturally?
----------
Just to show I'm not picking on Go, I'm pretty sure one could create a Go framework more like this, I just haven't seen it:
type GetPersonRequest struct {
Request `path:/people/{personId}`
PersonId int `param:path`
}
func GetPerson(personRequest GetPersonRequest) Person {
return db.GetPerson(personRequest.PersonId)
}
I think you'd have to have the request object because Go can annotate struct fields (with struct tags), but can't annotate method parameters or functions (but I could be wrong). The point is that most languages/frameworks don't have the spec information in the code in an easy way to reflect on like JAX-RS, ASP.NET APIs, and some others do.Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#29When 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 sho…
Re: Show HN: Auto-generate an OpenAPI spec by listening to localhost
#30I think pairing this tool with something that recursively clicks through app would be insanely helpful. (the latter is what I have trouble finding)
Open to ideas! We're thinking of adding agents/crawler suggestions to the github if there's a package that clicks around in that fashion
1. Wouldnt this also be helpful in understanding the exact nature of all traffic/calls against a particular page, user-workflow matriculating through your site from a UX perspective?
2. Could one make a proxy from this on a local home egress such that you could see the nature of outbound network traffic to site you visit (more importantly, traffic heading to 3rd-party trackers/cookies' APIs via your site visits?
3. Could it be used to nefariously map open API endpoints against a system one is (whiteHat) pen testing?