a) involves an incredible amount of DRY in the specs (to the extend we tinkered with a DSL to generate the openapi which feels wrong)
b) doesn't have very good ways of splitting large files up and
c) is YAML which is horrible. (Yes, JSON too, but that's even worse for authoring).
I can see if you're trying to describe an existing API with OpenAPI there are enhancements here which you will welcome.
If you're using OpenAPI to develop new APIs, I've come to the conclusion of "don't. Use GraphQL". After initially worrying about over-fetching and N+1 stuff, and thinking "yeah GraphQL for the front end, but the serious stuff should be OpenAPI" I've ditched that. GQL Federation was the final nail; it /does/ force some conversations up the chain (how exactly ought two, supposedly completely independent APIs, federate) but in practice this is a useful attribute.
a) involves an incredible amount of DRY in the specs (to the extend we tinkered with a DSL to generate the openapi which feels wrong) b) doesn't have very good ways of splitting large files up and c) is YAML which is horrible. (Yes, JSON too, but that's even worse for authoring).
I can see if you're trying to describe an existing API with OpenAPI there are enhancements here which you will welcome.
If you're using OpenAPI to develop new APIs, I've come to the conclusion of "don't. Use GraphQL". After initially worrying about over-fetching and N+1 stuff, and thinking "yeah GraphQL for the front end, but the serious stuff should be OpenAPI" I've ditched that. GQL Federation was the final nail; it /does/ force some conversations up the chain (how exactly ought two, supposedly completely independent APIs, federate) but in practice this is a useful attribute.