This looks super cool, I’ve played around with making custom API clients/executers in multiple teams now and am glad to see something that I might actually use instead of re-rolling my own each time.
One thing I’ve previously found very useful is the ability to select multiple ‘environments’ at once (I’ve previously split this in to e.g. environment+session or environment+user before). The ability to merge a set of variables together lets you define variables for _where_ I’m calling (local, staging, etc), but also who/what I’m calling (specific users, types of profiles/packages (how does this api behave if I switch between a free vs paid licence), etc).
Also echoing another comment, the blog linked gives me a 404 page now. Additionally, the GitHub for this projects seems have a ton of blank issues saying “help yapi made me too productive”? Rather odd, I probably won’t be running this project directly anytime soon…
well - the point is. that we wanted to be standards compliant - and want to use existing technologies without actually reiventing a new standard or a proprietary format. (like some of the other api clients took).
and moreover we had this fundamental idea that documentation and testing should be in a single source of truth to avoid documentation drift (not just the spec drift).
And hence we came up with the idea of using markdown as the baseline and doing everything around it.
Thank you for commenting about the 404. I'm serving the blog using a [custom package that serves your blog from GitHub hosted mark down](https://github.com/jamierpond/madea-blog-core) which was getting it's debut. There was a bug in caching requests to GitHub.
I love file-based API clients. I think it’s only time to define a standard file format that all or most IDEs, editors and clients support. Fragmentation between IntelliJ, VSCode and any other tool makes the approach less useful as it could be.
Looks neat! I highly recommend showcasing the interactivity with a few GIFs in your README. You can script them with https://github.com/charmbracelet/vhs
This looks super cool, I’ve played around with making custom API clients/executers in multiple teams now and am glad to see something that I might actually use instead of re-rolling my own each time.
One thing I’ve previously found very useful is the ability to select multiple ‘environments’ at once (I’ve previously split this in to e.g. environment+session or environment+user before). The ability to merge a set of variables together lets you define variables for _where_ I’m calling (local, staging, etc), but also who/what I’m calling (specific users, types of profiles/packages (how does this api behave if I switch between a free vs paid licence), etc).
Also echoing another comment, the blog linked gives me a 404 page now. Additionally, the GitHub for this projects seems have a ton of blank issues saying “help yapi made me too productive”? Rather odd, I probably won’t be running this project directly anytime soon…
Great to see this space so active !
Building something similar : https://voiden.md
Love this.
As a literate code aligned shop, we wish more tools adopted these values for knowledge-base-adjacent tasks.
// Love OP's CLI too!
Thank youuu !
We are open to feedback : https://github.com/VoidenHQ/feedback
This is a really interesting approach! How did you end up deciding on executable markdown as opposed to other approaches?
well - the point is. that we wanted to be standards compliant - and want to use existing technologies without actually reiventing a new standard or a proprietary format. (like some of the other api clients took).
and moreover we had this fundamental idea that documentation and testing should be in a single source of truth to avoid documentation drift (not just the spec drift).
And hence we came up with the idea of using markdown as the baseline and doing everything around it.
Is there a way to generate code from these specs? Perhaps via OpenAPI, Smithy, something like that?
I'm getting a 404 with the submitted link, but am able to view the homepage at https://yapi.run/.
Thank you for commenting about the 404. I'm serving the blog using a [custom package that serves your blog from GitHub hosted mark down](https://github.com/jamierpond/madea-blog-core) which was getting it's debut. There was a bug in caching requests to GitHub.
I love file-based API clients. I think it’s only time to define a standard file format that all or most IDEs, editors and clients support. Fragmentation between IntelliJ, VSCode and any other tool makes the approach less useful as it could be.
Yes! Exactly :) That is my plan.
Looks neat! I highly recommend showcasing the interactivity with a few GIFs in your README. You can script them with https://github.com/charmbracelet/vhs
No
Anyone else getting 404 when clicking the title[0] ?
[0]: https://yapi.run/blog/what-is-yapi
Page currently shows
Very nice. Just did not find the spec/format for the config file.
Hurl's another great option for this https://hurl.dev/