REST não requer JSON ou HTTP / 1.1
Você pode construir trivialmente um serviço RESTful que envia mensagens protobuf (ou qualquer outra coisa) por HTTP / 2
Você pode construir serviços RESTful que enviam JSON sobre HTTP / 2
Você pode construir serviços RESTful que enviam mensagens protobuf sobre HTTP / 1.1
Os serviços RESTful não são um "hack" no topo do HTTP / xx, são serviços que seguem os princípios arquitetônicos fundamentais que tornaram qualquer versão do HTTP bem-sucedida (como a capacidade de cache de solicitações GET e a capacidade de reprodução de solicitações PUT).
gRPC, SOAP, et. todos são mais como hacks - hacks em cima de HTTP para criar um túnel de serviços no estilo RPC sobre HTTP, para contornar as restrições de firewall e middlebox. Isso não é necessariamente uma coisa ruim. Às vezes, você pode querer um serviço do estilo RPC em vez de um REST, e temos que viver em um mundo onde middleboxes são difíceis de substituir.
Se você não tem tempo para ler sobre a definição real de REST:
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
Sempre há o TLDR; versão na wikipedia:
https://en.wikipedia.org/wiki/Representational_state_transfer
Se você precisa de um serviço no estilo RPC, com certeza, o gRPC é ótimo. Se você deseja viver na web ou deseja todos os benefícios que vêm com um serviço de estilo RESTful, crie um serviço de estilo RESTful. E se for muito lento serializar / desserializar dados no formato JSON em seu serviço restful, é perfeitamente normal usar protobuf ou qualquer outro.
Se gRPC for uma versão 2 de qualquer coisa, é uma versão 2 do SOAP. Um que não seja terrível, como o SOAP.
E, não, você não pode simplesmente "chamar qualquer função" em sua solicitação GET e ter um serviço RESTful.
Uma última coisa: se você for usar protobufs em um serviço RESTful, faça certo, usando cabeçalhos de tipo de conteúdo, etc. Com isso, você pode facilmente suportar JSON E protobuf.
Saindo da minha caixa SOAP agora ..;)