The post says it is a post-only API. I’m not sure if thats to a single URI, like graphql, or if the URI is different depending on the RPC call in use. But either way, it sounds like cacheability might not be great, which is also an issue with graphql.

That said, it’s definitely a step in the right direction, and I personally have never written an API where I even wanted the results to be cached.

The URI is per-RPC, specifically at /service/method, if that helps.

On cacheability, do check out https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.

I understand that is does not come with a proxy which is a leap forward. GETs are often optimized in various ways and gRPC is designed for reusing channels.