https://google.aip.dev/ gives lots of advice for structuring a gRPC API. What you say is mostly in line with that, with some exceptions. For example https://google.aip.dev/135 suggests that a delete operation on a resource should normally return google.protobuf.Empty. Of course, this is implicitly a sum type; you either get an empty response or an error message. If you needed to return anything else, you're not just implementing a delete. Two exceptions they call out are soft-deletes (not just a delete...) returning the resource itself, and a delete that's a long-running operation.

Wait but what about EmptyMessage and Any? Yes they're both terrible choices for any circumstance, but also widely seen.

I dunno. I'm simply recalling what I remember as best-practices by memory, could've been wrong about some of them, but for my own protobufs that I use I keep the same practice.

No, you're right. EmptyMessage exists but you shouldn't make it an input or output to an RPC if that RPC might ever in the future accept or return arguments. Since people are super bad about predicting the future, just call it WhateverRequest and WhateverReply and if there are no arguments today, don't put any fields in those types.

I would also not use Any as a request or reply type, but Any, in general, is fairly common in practical use.

But mainly for that reason, I would like to keep as much as backward compatibility, and if I have need to add a field, I can do it without changing some other function. (If need to, I'll add it in both places). Hard to tell really, for some things it might not make sense at all.