akshayjshah
commented
2 years ago Hi @nico151999 - thanks for explaining what you're looking for! This is a discussion we're tracking in https://github.com/bufbuild/connect-go/discussions/277.
We're very familiar with the Google HTTP annotations. It'd be very helpful if you could add a comment on #277 explaining why you need fine-grained control over paths and HTTP methods - in our view, this degree of configurability sacrifices simplicity and predictability.
I'm going to close this issue in favor of #277 - we can continue the discussion there.
emcfarlane
Is your feature request related to a problem? Please describe. I would like to be able to use connect-go like a REST API with user-defined paths and HTTP methods (using the option google.api.http in my proto files) as described here.
Describe the solution you'd like The connect protocol is definitely not redundant. If users do not define a REST mapping using google.api.http option for each of their RPC calls they might still find it useful to have a POST-only default fallback they can use with any HTTP client. The connect protocol does this well. However, those who define REST mappings in their proto files should get a respective REST endpoint. It is to be discussed if those RPCs that have a REST mapping defined should actually have a REST endpoint that replaces the POST-only default endpoint of the connect protocol or have a REST endpoint that co-exists with the connect protocol's POST-only default endpoint.
Describe alternatives you've considered Envoy can serve as a translation layer for gRPC web and REST to gRPC but in a minimal setup one might not want to depend on an Envoy instance.