8 ms·

Show HN: A faster way to prototype your APIs using OpenAPI 3 and Swagger UI

77 points by yehors 6y ago

hardwaresofton 6y ago
Hey you might want to note a bit more about what exactly this does and how it does it on the README. I went to the page and was thoroughly confused -- does this library: - Read application code (written in python?) and extract an API specification? Is it flask only? - Does it update the file on disk repeatedly? - Does it modify generated application code to add an endpoint for the Swagger UI and host it? - Are any modifications to the pre-existing applications necessary? - Does it wrap an existing application? Good tools also often have a comparison section -- are there other tools in your space that do what you do, but differently? I'd like to think I'm familiar with the Swagger/Swagger2/OpenAPI3 space, and I'm aware of tools that go spec->code (usually generating clients/servers) and code->spec (whether by comments, annotations, or some other language mechanism), but it's not clear what your tool actually does.
- yehors 6y ago
  Hello. Yes, I have not prepared enough the description so guys and ladies I am sorry for that. Just added more information to the README.md file on GitHub. Answers to the questions: > - Read application code (written in python?) and extract an API specification? Is it flask only? You can: 1. Construct schema objects and request objects using Python classes with marshmallow [1] library; 2. Split API paths (routes) into separate python modules, files for convenience and then add them in the `api/project.py` file. > - Does it update the file on disk repeatedly? No. You need to re-build the `api.yaml` file by yourself, using this command: "python build.py" > - Does it modify generated application code to add an endpoint for the Swagger UI and host it? No. You need to write the business logic of your API by yourself. For example, you write an API in Go and describe the API definitions (specifications) using my project just by adding new paths, schemas. Flask is used only for development purposes, it is not meant to create API using Flask, but you can do it as well. > - Are any modifications to the pre-existing applications necessary? No. > - Does it wrap an existing application? If you meant if this is a wrapper for other apps then it is. These two: marshmallow [1] and apispec [2] If you meant if this wraps existed API then the answer is yes. You can describe existing APIs using my project. > ... are there other tools in your space that do what you do, but differently? Yes, a lot and for many languages. I can mention swagger-php [3], flask-swagger [4] which I know. But the two are using annotations in code (via docstrings) to describe the API definitions/specification when my project is meant to create ONLY API defs/spec. [1]: https://marshmallow.readthedocs.io/en/stable/ https://marshmallow.readthedocs.io/en/stable/ [2]: https://github.com/marshmallow-code/apispec https://github.com/marshmallow-code/apispec [3]: https://github.com/zircote/swagger-php https://github.com/zircote/swagger-php [4]: https://pypi.org/project/flask-swagger/ https://pypi.org/project/flask-swagger/
  - hardwaresofton 6y ago
    Thanks for the detailed answers! You know what would make it really clear -- a "Quick Start" section, show me how to go from 0 to 1 with your library. From what I can gather: - `pip install` your library - create a golang project - write some routes (and annotate them accordingly) - call your library via `python ...` (?) - api.yaml is written to my directory Thanks for open sourcing this software!
    - yehors 6y ago
      This quote came to my mind after your comment: "It is necessary to light it up so that it shines. (Inscription on Kubachi lamps)". Yesterday I extended the README file so you can start using information from this section: https://github.com/egorsmkv/openapi3-generator#how-to-use https://github.com/egorsmkv/openapi3-generator#how-to-use As I said before the project isn't related to business logic of your APIs but I can show you an example how you could use it. It's an example about how to create an API in Go. After generating an api.yaml file go to api-spec-converter [1] and convert content of API spec in OpenAPI 3 format to Swagger 2. Then download an executable file of go-swagger [2] and run this command to generate all boilerplate code for your server: swagger generate server -f ./swagger.json -A pet-api This way you can firstly prototype (describe all paths, schemes, and requests) of your API and only then to start to write code. It's hugely simplifying the process of coding in my opinion. [1]: https://lucybot-inc.github.io/api-spec-converter/ https://lucybot-inc.github.io/api-spec-converter/ [2]: https://github.com/go-swagger/go-swagger https://github.com/go-swagger/go-swagger
      - hardwaresofton 6y ago
        Thanks for going above and beyond on the documentation -- I finally understand exactly where it fits!
adenta 6y ago
As 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, because that’s what I am most familiar developing in. I understand rails is a sub optimal choice for this project.) In the time I wasted trying to find a generator, I could’ve just wrote the code by hand. Once I just started manually writing code, everything started moving much quicker. Even if I had used a generator, I’d still need to manually update things every time the interface changes, yeah? Who is openAPI for?
- smt88 6y ago
  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 of error-prone work. It also forms an unbreakable contract between systems in totally different languages (not unlike what Protobufs could be used for). It takes a few hours to find tools you like, but after that, it's generally smooth.
  - rolha-capoeira 6y ago
    What tools do you use?
    - smt88 6y ago
      See sibling comments for some links
  - 0xffff2 6y ago
    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.
kapilvt 6y ago
went through the code, there's nothing here that i can see. its just a demo pet store app in flask.
- OJFord 6y ago
  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.
_the_special_ 6y ago
the README file of this repo does not help me understand what this project is about as someone who has never used OpenAPI (and only faintly used Swagger UI for a short time before).
dvlx 6y ago
Even easier with FastApi https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/ Auto generates both interactive SwaggerUI and Redoc pages. Can turn off before production deployment.
- mccolin 6y ago
  Seconded. FastAPI has been a boon for us in our project work and the auto-generated documentation is one of its very best features.
- gtm1260 6y ago
  Came here to say this, FastApi was my introduction to Swagger and now I love it!
- hardwaresofton 6y ago
  This was a fantastic introduction to modern performant/typesafe python -- I had no idea FastAPI existed, and did not know about the projects it depends on, starlette[0] and pydantic[1]. Prior to today if I was starting a python project I probably would reach for PyPy + falcon/flask/django and go until I hit a limitation that required CPython, but with starlette/pydantic I'm more than happy to settle for NodeJS-like performance on CPython. And of course, the OpenAPI/Swagger support is an amazing feature, APIs shouldn't be built without it these days. [0]: https://starlette.io/ https://starlette.io/ [1]: https://pydantic-docs.helpmanual.io/ https://pydantic-docs.helpmanual.io/
Twisell 6y ago
As 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.
OJFord 6y ago
Shameless 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 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/slides.pdf https://github.com/OJFord/tapioca/releases/download/v0.0.1/s...
BerislavLopac 6y ago
Shameless 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. [0] https://pyotr.readthedocs.io https://pyotr.readthedocs.io [1] https://www.starlette.io/ https://www.starlette.io/ [2] https://www.python-httpx.org/ https://www.python-httpx.org/
- hardwaresofton 6y ago
  Hey just to let you know -- the reason I'd pick something like FastAPI over pyotr is because I don't want to write the OpenAPI -- I personally see code on the backend as the source of truth, and prefer for it to go the other way (Swagger/OpenAPI YAML/JSON generated from code). Other than that, library looks cool! like connexion[0] but starlette based. Might be worth putting a comparison on your page? [0]: https://github.com/zalando/connexion https://github.com/zalando/connexion
  - BerislavLopac 6y ago
    Thank you for the kind words! > I personally see code on the backend as the source of truth That is a perfectly valid approach, although when you need to coordinate development between multiple teams starting with a specification can be really helpful. That doesn't mean that the spec has to be written once and frozen, as long as everyone is aware of the changes and adapts accordingly. > Might be worth putting a comparison on your page? I have indeed started the development when I found that connexion does not completely meet my requirements. The main difference is that pyotr supports ASGI, so can work with any ASGI framework (I haven't tried it with Mangum yet, but am planning to). Additionally, pyotr has a client component, which was inspired by Bravado.
    - hardwaresofton 6y ago
      > That is a perfectly valid approach, although when you need to coordinate development between multiple teams starting with a specification can be really helpful. That doesn't mean that the spec has to be written once and frozen, as long as everyone is aware of the changes and adapts accordingly. True! I wonder if there's a good way to actually keep teams abreast. I actually end up writing specs by hand from time to time when I just want to get started quickly, but it can be such a pain. Oh but one of the cool things I was able to set up is automatic generation of client libs (and pushing to a git repo) with GitLab -- it's really awesome to be able to automatically generate client libs that match your API versions. > I have indeed started the development when I found that connexion does not completely meet my requirements. The main difference is that pyotr supports ASGI, so can work with any ASGI framework (I haven't tried it with Mangum yet, but am planning to). Additionally, pyotr has a client component, which was inspired by Bravado. So I didn't actually know what ASGI was until I read your existing documentation! I'm not a huge python person but I'd heard of WSGI and some of the other variants but hadn't heard of ASGI! Thanks for the background on the client as well
codenesium 6y ago
Shameless plug! Generate a .net core skeleton from a OpenAPI spec. It's a work in progress. https://www.codenesium.com/projects https://www.codenesium.com/projects
carapace 6y ago
I'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?)
tlarkworthy 6y ago
I am confused when people try to generate api specs from languages (e.g. typescript to openAPI). The big draw to API specs for me is language independence. By generating from an implementation it's the wrong way round and you lose a degree of freedom IMHO.
- yehors 6y ago
  I agree with this position. The code and the API spec must be separated. But the project is not meant to write APIs with spec, the project uses Python to create API spec.
apocalyptic0n3 6y ago
Just a heads up, there are a number of similar/identically named projects: - https://openapi-generator.tech/ https://openapi-generator.tech/ - https://github.com/zijianhuang/openapiclientgen https://github.com/zijianhuang/openapiclientgen - https://github.com/deepmap/oapi-codegen https://github.com/deepmap/oapi-codegen I swear I've come across a few others while looking for the best web visualizer (mostly settled on Redoc), but I'm not finding them on https://openapi.tools/ https://openapi.tools/ or http://openapi.toolbox.apievangelist.com http://openapi.toolbox.apievangelist.com, so perhaps they've been abandoned
Nijikokun 6y ago
Insomnia Designer can help you develop and manage your OpenAPI specs as well :) https://insomnia.rest/products/designer https://insomnia.rest/products/designer
- riquito 6y ago
  Thanks, the comment is on topic and could be useful to some, but please mention affiliation when suggesting a product

77 points by yehors 6y ago

Hey you might want to note a bit more about what exactly this does and how it does it on the README. I went to the page and was thoroughly confused -- does this library: - Read application code (written in python?) and extract an API specification? Is it flask only? - Does it update the file on disk repeatedly? - Does it modify generated application code to add an endpoint for the Swagger UI and host it? - Are any modifications to the pre-existing applications necessary? - Does it wrap an existing application? Good tools also often have a comparison section -- are there other tools in your space that do what you do, but differently? I'd like to think I'm familiar with the Swagger/Swagger2/OpenAPI3 space, and I'm aware of tools that go spec->code (usually generating clients/servers) and code->spec (whether by comments, annotations, or some other language mechanism), but it's not clear what your tool actually does.

yehors 6y ago
Hello. Yes, I have not prepared enough the description so guys and ladies I am sorry for that. Just added more information to the README.md file on GitHub. Answers to the questions: > - Read application code (written in python?) and extract an API specification? Is it flask only? You can: 1. Construct schema objects and request objects using Python classes with marshmallow [1] library; 2. Split API paths (routes) into separate python modules, files for convenience and then add them in the `api/project.py` file. > - Does it update the file on disk repeatedly? No. You need to re-build the `api.yaml` file by yourself, using this command: "python build.py" > - Does it modify generated application code to add an endpoint for the Swagger UI and host it? No. You need to write the business logic of your API by yourself. For example, you write an API in Go and describe the API definitions (specifications) using my project just by adding new paths, schemas. Flask is used only for development purposes, it is not meant to create API using Flask, but you can do it as well. > - Are any modifications to the pre-existing applications necessary? No. > - Does it wrap an existing application? If you meant if this is a wrapper for other apps then it is. These two: marshmallow [1] and apispec [2] If you meant if this wraps existed API then the answer is yes. You can describe existing APIs using my project. > ... are there other tools in your space that do what you do, but differently? Yes, a lot and for many languages. I can mention swagger-php [3], flask-swagger [4] which I know. But the two are using annotations in code (via docstrings) to describe the API definitions/specification when my project is meant to create ONLY API defs/spec. [1]: https://marshmallow.readthedocs.io/en/stable/ https://marshmallow.readthedocs.io/en/stable/ [2]: https://github.com/marshmallow-code/apispec https://github.com/marshmallow-code/apispec [3]: https://github.com/zircote/swagger-php https://github.com/zircote/swagger-php [4]: https://pypi.org/project/flask-swagger/ https://pypi.org/project/flask-swagger/
- hardwaresofton 6y ago
  Thanks for the detailed answers! You know what would make it really clear -- a "Quick Start" section, show me how to go from 0 to 1 with your library. From what I can gather: - `pip install` your library - create a golang project - write some routes (and annotate them accordingly) - call your library via `python ...` (?) - api.yaml is written to my directory Thanks for open sourcing this software!
  - yehors 6y ago
    This quote came to my mind after your comment: "It is necessary to light it up so that it shines. (Inscription on Kubachi lamps)". Yesterday I extended the README file so you can start using information from this section: https://github.com/egorsmkv/openapi3-generator#how-to-use https://github.com/egorsmkv/openapi3-generator#how-to-use As I said before the project isn't related to business logic of your APIs but I can show you an example how you could use it. It's an example about how to create an API in Go. After generating an api.yaml file go to api-spec-converter [1] and convert content of API spec in OpenAPI 3 format to Swagger 2. Then download an executable file of go-swagger [2] and run this command to generate all boilerplate code for your server: swagger generate server -f ./swagger.json -A pet-api This way you can firstly prototype (describe all paths, schemes, and requests) of your API and only then to start to write code. It's hugely simplifying the process of coding in my opinion. [1]: https://lucybot-inc.github.io/api-spec-converter/ https://lucybot-inc.github.io/api-spec-converter/ [2]: https://github.com/go-swagger/go-swagger https://github.com/go-swagger/go-swagger
    - hardwaresofton 6y ago
      Thanks for going above and beyond on the documentation -- I finally understand exactly where it fits!

adenta 6y ago

As 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, because that’s what I am most familiar developing in. I understand rails is a sub optimal choice for this project.) In the time I wasted trying to find a generator, I could’ve just wrote the code by hand. Once I just started manually writing code, everything started moving much quicker. Even if I had used a generator, I’d still need to manually update things every time the interface changes, yeah? Who is openAPI for?

smt88 6y ago
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 of error-prone work. It also forms an unbreakable contract between systems in totally different languages (not unlike what Protobufs could be used for). It takes a few hours to find tools you like, but after that, it's generally smooth.
- rolha-capoeira 6y ago
  What tools do you use?
  - smt88 6y ago
    See sibling comments for some links
- 0xffff2 6y ago
  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.

kapilvt 6y ago

went through the code, there's nothing here that i can see. its just a demo pet store app in flask.

OJFord 6y ago
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.

_the_special_ 6y ago

the README file of this repo does not help me understand what this project is about as someone who has never used OpenAPI (and only faintly used Swagger UI for a short time before).

dvlx 6y ago

Even easier with FastApi https://fastapi.tiangolo.com/ https://fastapi.tiangolo.com/ Auto generates both interactive SwaggerUI and Redoc pages. Can turn off before production deployment.

mccolin 6y ago
Seconded. FastAPI has been a boon for us in our project work and the auto-generated documentation is one of its very best features.
gtm1260 6y ago
Came here to say this, FastApi was my introduction to Swagger and now I love it!
hardwaresofton 6y ago
This was a fantastic introduction to modern performant/typesafe python -- I had no idea FastAPI existed, and did not know about the projects it depends on, starlette[0] and pydantic[1]. Prior to today if I was starting a python project I probably would reach for PyPy + falcon/flask/django and go until I hit a limitation that required CPython, but with starlette/pydantic I'm more than happy to settle for NodeJS-like performance on CPython. And of course, the OpenAPI/Swagger support is an amazing feature, APIs shouldn't be built without it these days. [0]: https://starlette.io/ https://starlette.io/ [1]: https://pydantic-docs.helpmanual.io/ https://pydantic-docs.helpmanual.io/

Twisell 6y ago

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

OJFord 6y ago

Shameless 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 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/slides.pdf https://github.com/OJFord/tapioca/releases/download/v0.0.1/s...

BerislavLopac 6y ago

Shameless 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. [0] https://pyotr.readthedocs.io https://pyotr.readthedocs.io [1] https://www.starlette.io/ https://www.starlette.io/ [2] https://www.python-httpx.org/ https://www.python-httpx.org/

hardwaresofton 6y ago
Hey just to let you know -- the reason I'd pick something like FastAPI over pyotr is because I don't want to write the OpenAPI -- I personally see code on the backend as the source of truth, and prefer for it to go the other way (Swagger/OpenAPI YAML/JSON generated from code). Other than that, library looks cool! like connexion[0] but starlette based. Might be worth putting a comparison on your page? [0]: https://github.com/zalando/connexion https://github.com/zalando/connexion
- BerislavLopac 6y ago
  Thank you for the kind words! > I personally see code on the backend as the source of truth That is a perfectly valid approach, although when you need to coordinate development between multiple teams starting with a specification can be really helpful. That doesn't mean that the spec has to be written once and frozen, as long as everyone is aware of the changes and adapts accordingly. > Might be worth putting a comparison on your page? I have indeed started the development when I found that connexion does not completely meet my requirements. The main difference is that pyotr supports ASGI, so can work with any ASGI framework (I haven't tried it with Mangum yet, but am planning to). Additionally, pyotr has a client component, which was inspired by Bravado.
  - hardwaresofton 6y ago
    > That is a perfectly valid approach, although when you need to coordinate development between multiple teams starting with a specification can be really helpful. That doesn't mean that the spec has to be written once and frozen, as long as everyone is aware of the changes and adapts accordingly. True! I wonder if there's a good way to actually keep teams abreast. I actually end up writing specs by hand from time to time when I just want to get started quickly, but it can be such a pain. Oh but one of the cool things I was able to set up is automatic generation of client libs (and pushing to a git repo) with GitLab -- it's really awesome to be able to automatically generate client libs that match your API versions. > I have indeed started the development when I found that connexion does not completely meet my requirements. The main difference is that pyotr supports ASGI, so can work with any ASGI framework (I haven't tried it with Mangum yet, but am planning to). Additionally, pyotr has a client component, which was inspired by Bravado. So I didn't actually know what ASGI was until I read your existing documentation! I'm not a huge python person but I'd heard of WSGI and some of the other variants but hadn't heard of ASGI! Thanks for the background on the client as well

codenesium 6y ago

Shameless plug! Generate a .net core skeleton from a OpenAPI spec. It's a work in progress. https://www.codenesium.com/projects https://www.codenesium.com/projects

carapace 6y ago

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

tlarkworthy 6y ago

I am confused when people try to generate api specs from languages (e.g. typescript to openAPI). The big draw to API specs for me is language independence. By generating from an implementation it's the wrong way round and you lose a degree of freedom IMHO.

yehors 6y ago
I agree with this position. The code and the API spec must be separated. But the project is not meant to write APIs with spec, the project uses Python to create API spec.

apocalyptic0n3 6y ago

Just a heads up, there are a number of similar/identically named projects: - https://openapi-generator.tech/ https://openapi-generator.tech/ - https://github.com/zijianhuang/openapiclientgen https://github.com/zijianhuang/openapiclientgen - https://github.com/deepmap/oapi-codegen https://github.com/deepmap/oapi-codegen I swear I've come across a few others while looking for the best web visualizer (mostly settled on Redoc), but I'm not finding them on https://openapi.tools/ https://openapi.tools/ or http://openapi.toolbox.apievangelist.com http://openapi.toolbox.apievangelist.com, so perhaps they've been abandoned

Nijikokun 6y ago

Insomnia Designer can help you develop and manage your OpenAPI specs as well :) https://insomnia.rest/products/designer https://insomnia.rest/products/designer

riquito 6y ago
Thanks, the comment is on topic and could be useful to some, but please mention affiliation when suggesting a product