Hacker News new | past | comments | ask | show | jobs | submit login

There are thousands of companies with production APIs that don’t adhere to any specification, let alone OAS.

On top of that, Companies that were considering OAS now have GraphQL APIs instead — or even JSONAPI. When we need to respond to the needs of one of these companies, we need to move quickly.

I think we’re just comparing apples and oranges. We’re working on solving API integration issues in a real way, which means we build the tool for the job. OAS is an idealized, democratic position that — while absolutely a best -in-market solution — does not directly and meaningfully incentivize companies to rely upon it.




As 'codegladiator indicated, OpenAPI is descriptive, not prescriptive. If you have an API that cannot be described in OpenAPI, that is a bug in OpenAPI. And personally, I've literally never seen an HTTP-based, non-GraphQL API that cannot be expressed, and fairly easily, in OpenAPI and even in a subset that can generate programmatically "acceptable" to "great" API clients in a variety of languages. Heck, it's not even that hard to make a RPC-based API with XML as its lingua franca work just fine in OpenAPI.

Now, you're correct about GraphQL, but it's also apparently not super relevant, as the APIs you're trumpeting on your site are overwhelmingly either RESTful or adjacent to RESTful. But even so? You could pretty easily have vendor extensions (`x-` properties) for GraphQL--ones that in the future maybe even become canonical ones!--in OpenAPI while using it for standard APIs, an approach whose deficiencies you've consistently chosen to retreat from after you state them.

This fundamental misapprehension about specification versus description, and the way you dropped your "serverless function schema" claims like a hot rock (and I want to underline that the offer to work to improve OAS wherever it happens to lack is genuine and is work I am very happy to do) and the absolute unwillingness to address any question that touches on your obvious attempts at barriers to entry, frankly, makes you think you're just bullshitting me.

I'd like to wish you well, but you have demonstrated to my satisfaction your intent to piss in the public pool for your own benefit. I wish you wouldn't be so bound and determined to do so.


Alright.

To be direct, I don’t really understand your criticism — we’re a small team working like crazy to create value for folks. I get that you don’t like the way we’ve implemented our own specifications, and that’s okay, but to be honest I’m a little offput that you’re accusing me of bullshitting when I believe I’ve been straightforward with you.

If you’d like to use the product / platform and work with us to make things better, we’d love the support!


Wow. GitHub's CEO is an investor in this Autocodes? Nat is known for Open SOurce since it started.


> don’t adhere to any specification, let alone OAS

OAS is not a specification to adhere. It is a specification to describe.

> OAS now have GraphQL APIs instead — or even JSONAPI

OAS is orthogonal to GraphQL/JSONAPI. With OAS you describe what the API is which could be JSONAPI or some custom API adhering no standard.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: