Live data from Hacker News

A Deep Dive into OpenAPI

deployhq.com

11–18 of 18 posts

Re: A Deep Dive into OpenAPI

#12

Earlier quoted context omitted.

I would say being verbose is a positive thing. It removes the need of having additional (and usually out-of-sync) documentation. Plus all the tooling around it that allows you to keep public Dev documentation in sync with min effort.

Agreed. The extra stuff you get "for free" from the OpenAPI ecosystem is well worth the extra time it takes to write the spec. If you don't want things like client/server generators and documentation, then sure it's not great

You still need to write a spec with protobufs. It's just that the spec is much more succinct and easy to read. And you can generate docs from it. E.g.:

https://cloud.google.com/appengine/docs/admin-api/reference/...

Do an experiment, take a Protobuf spec for some Google API and convert it into OpenAPI.

Re: A Deep Dive into OpenAPI

#15

Earlier quoted context omitted.

I would say being verbose is a positive thing. It removes the need of having additional (and usually out-of-sync) documentation. Plus all the tooling around it that allows you to keep public Dev documentation in sync with min effort.

Agreed. The extra stuff you get "for free" from the OpenAPI ecosystem is well worth the extra time it takes to write the spec. If you don't want things like client/server generators and documentation, then sure it's not great

We have used the gem: https://github.com/a-chacon/oas_rails, and we didn't need to write the specs, just comment the endpoints

Re: A Deep Dive into OpenAPI

#18
post #4

Ugh. OpenAPI: just say "no". It's WAY too verbose, and there are usually many ways to shoot yourself in the foot. Protobuf-based APIs are much nicer to work with. Either via gRPC, or via ConnectRPC.

I remember twirp being quite nice, too. Especially since it would also handle json from the same proto file.
Post reply on HN