Even easier with FastApi
Auto generates both interactive SwaggerUI and Redoc pages.
Can turn off before production deployment.
Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
11–20 of 42 posts
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#12went through the code, there's nothing here that i can see. its just a demo pet store app in flask.
No, it's confusing, but it is doing something - it's serialising marshmallow schemata into a OpenAPI/Swagger YAML file.
The serialiser is predominantly in `internal`, the example is in `api`.
But it's not very fleshed out, without checking thoroughly I think a lot must be unsupported yet.
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#13As other mentioned this the description is particularly non-user friendly for something that (as far as I understood) is related to a documentation management system.
I'm mostly a backend GUI but still interested in learning more about web API. But the only description sentence is presuming that reader is comfortable with a highly specialized jargon. On the other hand I smell that "any project" is probably far narrower than it sound.
> The goal of this project is to create a generator that conveniently creates API definitions in OpenAPI 3 format and then injects the generated YAML file with Swagger UI to any project.
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#14Shameless plug, I did something similar in Rust (that is, 2017 rust that I haven't gone back to) for my MEng project.
I really wish more APIs/people used OpenAPI, I think/thought it's fantastic, but I haven't really used it since. Docs-only at work, a bit, but it has so much more potential.
--
Main difference in mine is that I used the OpenAPI spec as the starting point though - I wanted to be able to use it as an API-specific HTTP client. From that I inferred type signatures at compile-time in order to enforce correct (per the spec) use of an API, and enforce handling all the (stated) possible error cases. Idea being that if you did the same on the server side, you'd have pretty good guarantees about your communication.
Kept meaning (still mean?) to go back to it, but I haven't yet. It supports the basics, but it's far from battle-tested; I might never get back to working on it, but if it's of interest to anyone for (absolutely non-production) toying around, I'll certainly respond and act on any PRs.
https://github.com/OJFord/tapioca
It seems they're not linked from the readme (probably I was scared to update it post-deadline in case of examiner doubt, and presentation/slide manufacture was post-submission deadline) but there's also slides (linked from the release) that perhaps have a bit more detail on what I was going for from a more technical perspective (though it's been a while):
https://github.com/OJFord/tapioca/releases/download/v0.0.1/s...
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#15Shameless plug: I have been developing Pyotr [0], a helpful async library - based on top of Starlette [1] and httpx [2] - which is using OpenAPI as the specification for routing and validation, both on server and client side.
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#16Shameless plug! Generate a .net core skeleton from a OpenAPI spec. It's a work in progress.
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#17As someone who used openAPI for the first time recently, I don’t understand the benefit. Im building an integration between two different API’s. I was given the openAPI spec and instructed to find a mock server generator to get a boilerplate app up. I spent like two hours trying to find some sort of generator that provides value. All the generators I tried seemed half baked (I wanted to use rails for this project, be…
Hey, I use it at work. It's really just a fairly stable way of documenting APIs. Sure you can try do fancy generation of it from one side, and generate code on the other, but treat it just as a standard way of talking about requests and responses and you'll see the benefits. If you do want a good benefit, here's a testing engine that'll run through an OpenAPI file and confirm the server's adhering to it correctly: ht…
This seems, so much more valuable than trying to use OpenAPI to generate server side code. Thanks!
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#18I've been out-of-the-loop for a while, what's the state of the art in re: OpenAPI/Swagger?
What I mean is, are people using it in the wild? Are there mature (or at least pretty stable) code generators? Test generators? What's inter-operability like? (Is it easy/possible to generate clients and server stubs in different languages that will work together? Can I write a service, publish my API spec, and expect people to be able to use it to write clients?)
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#19As someone who used openAPI for the first time recently, I don’t understand the benefit. Im building an integration between two different API’s. I was given the openAPI spec and instructed to find a mock server generator to get a boilerplate app up. I spent like two hours trying to find some sort of generator that provides value. All the generators I tried seemed half baked (I wanted to use rails for this project, be…
I work at a rather large company that has an internal gateway for all APIs. Each api has an associated OpenAPI doc and the standardization makes it incredibly easy to peruse all capabilities across the company, despite programming language, organizational, and physical barriers between developers. I concede that the magic there is in the standardization of API level docs, and not the special sauce that OpenAPI brings…
How do you deal with reasonably complex data structures in OpenAPI?
We're in desperate need of an API documentation solution, and i reached for OpenAPI early on but found it (the UIs availab,e specifically) immensely confusing. It looks great when it's a small flat object, but when you're returning hundreds of unique fields and structures, lots of enums, etc - the result is an automated mess.
I don't think this is strictly a fault of the spec, but of the UI. They seem to design it around the pet shop example, which doesn't seem beneficial to any of our internal, large API responses.
Thoughts?
Re: Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI
#20As someone who used openAPI for the first time recently, I don’t understand the benefit. Im building an integration between two different API’s. I was given the openAPI spec and instructed to find a mock server generator to get a boilerplate app up. I spent like two hours trying to find some sort of generator that provides value. All the generators I tried seemed half baked (I wanted to use rails for this project, be…
I have extensively used OpenAPI Specs for years. You're right that tools are almost all partially-baked. I use specs to generate data models in TypeScript, Kotlin, and .NET (for different projects). This gives me compile-time guarantees that my API docs match my code. I also use it for generating documentation and client SDKs in other languages. If used correctly, it can help automate hundreds or thousands of hours o…
I spend weeks looking for tools that I could even us, much less like, and eventually gave up and wrote everything by hand. I would be very interested in hearing about any OpenAPI tools that you would recommend.