Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
OpenAPI 3.0 Spec — Generate Directus API Clients (SDKs) #2255
We already have most of our Directus API 2.x endpoints/params within Paw for testing. We could finish adding all of these and then potentially use their code generators to create SDKs for our secondary languages.
We also have a Swagger file for 98% of API 1.1 — so we could update that (and make sure that OpenAPI allows for our filtering syntax now).
I'd love to get some thoughts from the community (and Core team) on this so we can finally get some momentum and wrap this up!
Quote of @wing328:
Right now openapi-generator is in 4.0.0-beta version. That version contains a lot of new features, codegens and even more important breaking changes.
I've created MySQL schema generator and I'm responsible for most of PHP Slim generator updates.
You can check difference of Slim generator output:
Quote of @wing328 again:
Hey @ybelenko — we have been struggling with OpenAPI/Swagger for a while, specifically with nested deepObjects used within our filtering parameters.
We would love to find an alternative that supports this syntax — do you know if OpenAPI Generator does?
Hey guys, I've been testing other headless CMSs that support automatic OpenAPI documentation. Those I've found are lacking other features that Directus supports.
So why wait until OAS is fully supporting nested filtering?
Another useful idea would be to use Directus bookmarks and make API routes out of them, also documented via OAS.
How do you think about that @benhaynes ?
Maybe an example helps:
In the app I want to display the podcast series, but only the ones that have one or more items in it.
In my mobile apps I could simply generate the networking client via the OpenAPI generator and be able to access this endpoint.
With this approach we would achieve some kind of static filtering, which could be useful for basic things like my example.
You could add that as an API feature request! See what the community thinks...
We have a spec from our old API (1.1) but can't spend the time to update this since we have no reassurance that OAS will support our filter syntax. If it were a lesser feature, maybe... but filtering is a huge part of the platform.
If you would like to take a shot updating the spec, we can offer guidance!