<story><title>OpenAPI v4 (aka Moonwalk) Proposal</title><url>https://github.com/OAI/moonwalk</url></story><parent_chain><item><author>mbell</author><text>I&amp;#x27;ve tried using OpenAPI a few times, it&amp;#x27;s been...lackluster... I probably won&amp;#x27;t use it again.&lt;p&gt;Here are my gripes:&lt;p&gt;1) For me one of the biggest selling points is client code gen (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;OpenAPITools&amp;#x2F;openapi-generator&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;OpenAPITools&amp;#x2F;openapi-generator&lt;/a&gt;). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn&amp;#x27;t compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.&lt;p&gt;2) JSONSchema is too limited. We use it for a lot of things, but it just makes some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).&lt;p&gt;On the pros side:&lt;p&gt;It does make pretty docs - kinda wish it would just focus on this and in the process not be as strict, I think it would be a better project.</text></item></parent_chain><comment><author>GOATS-</author><text>I find it odd that you&amp;#x27;ve struggled so much with generating API clients. I&amp;#x27;ve generated C# and TypeScript (Angular&amp;#x27;s HttpClient and React Query) clients for my API and never had any issues with them. With that being said, I didn&amp;#x27;t use OpenAPI&amp;#x27;s Java-based code generators and rather used ones made by third-party developers such as NSwag[0] and openapi-codegen[1].&lt;p&gt;[0]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RicoSuter&amp;#x2F;NSwag&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;RicoSuter&amp;#x2F;NSwag&lt;/a&gt;&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;fabien0102&amp;#x2F;openapi-codegen&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;fabien0102&amp;#x2F;openapi-codegen&lt;/a&gt;</text></comment>
<story><title>OpenAPI v4 (aka Moonwalk) Proposal</title><url>https://github.com/OAI/moonwalk</url></story><parent_chain><item><author>mbell</author><text>I&amp;#x27;ve tried using OpenAPI a few times, it&amp;#x27;s been...lackluster... I probably won&amp;#x27;t use it again.&lt;p&gt;Here are my gripes:&lt;p&gt;1) For me one of the biggest selling points is client code gen (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;OpenAPITools&amp;#x2F;openapi-generator&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;OpenAPITools&amp;#x2F;openapi-generator&lt;/a&gt;). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn&amp;#x27;t compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.&lt;p&gt;2) JSONSchema is too limited. We use it for a lot of things, but it just makes some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).&lt;p&gt;On the pros side:&lt;p&gt;It does make pretty docs - kinda wish it would just focus on this and in the process not be as strict, I think it would be a better project.</text></item></parent_chain><comment><author>simplesager</author><text>I&amp;#x27;m working on a company &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;speakeasyapi.dev&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;speakeasyapi.dev&amp;#x2F;&lt;/a&gt; with the goal of helping companies in this ecosystem get great production quality client sdks, terraform providers, cli(s) and all the developer surfaces you may want supported for our API. We also manage the spec and publishing workflow for you so all you have to do is build your API and we&amp;#x27;ll do the rest.&lt;p&gt;Feel free to email me at sagar@speakeasyapi.dev or join our slack (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;join.slack.com&amp;#x2F;t&amp;#x2F;speakeasy-dev&amp;#x2F;shared_invite&amp;#x2F;zt-1cwb3flxz-lS5SyZxAsF_3NOq5xc8Cjw&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;join.slack.com&amp;#x2F;t&amp;#x2F;speakeasy-dev&amp;#x2F;shared_invite&amp;#x2F;zt-1cwb...&lt;/a&gt;) . We&amp;#x27;re in open beta and working with a few great companies already and we&amp;#x27;d be happy for you to try out the platform for free!</text></comment>