Есть вот такая штука: github.com/...​pc-ecosystem/grpc-gateway.
Вот тут можно почитать про опыт использования: habr.com/ru/post/337716

А почему люди держатся за REST до сих пор? Ведь есть же и gRPC, и GraphQL. С последним я не работал, но после введения типов в язык описания тоже выглядит решением (developer.github.com/v4). Можно же сделать API на gRPC и выставить его через REST для тех, кому очень надо. Я догадываюсь, что причины могут быть: «У нас тут много легаси», «Люди на этом умеют работать.» А что ещё?

Паша, да oneof может приводить в switch-ам и if-ам так, что боги ООП по линии Страуструпа начинают бурчать и отворачиваться. А те, кто по линии Алана Кэя, те только хмурятся немного.

Да, кодогенерация — штука непростая. Но в нашем случае мы делаем не один API для нескольких языков, а инструмент для генерациии кода в каждом проекте, где будут сотни сообщений и десятки сущностей. Другими словами мы делаем инструмент, который бы позволял коллегам не мучиться так, как Вы описываете в своём опыте. Но область применения этого инструмента ограничена проектами на реактивном DDD.

По поводу обработки `null` на передающей стороне, то мы стараемся избегать `null`, с помощью тех же аннотаций из ErrorProne, например. А для micro-services Protobuf вполне применим. На нём gRPC строится, например.

В Protobuf нет `null`. Есть пустые сообщения, которые получаются через `Message.getDefaultInstanceForType()`. Это немного безопаснее, но не спасает от того, что про модель домена надо думать и заботиться о целостности данных. Именно поэтому мы и сделали валидацию данных (см. опцию `(required)` в нашей статье).