feat: support gRPC HTTP mapping annotation for grpc trancode plugin

[sysulq]

We can use gRPC HTTP mapping annotation to specifies the HTTP mapping for methods in protobuf as well, like this:

// Returns a specific bookstore shelf.
rpc GetShelf(GetShelfRequest) returns (Shelf) {
  // Client example - returns the first shelf:
  //   curl http://DOMAIN_NAME/v1/shelves/1
  option (google.api.http) = { get: "/v1/shelves/{shelf}" };
}

...
// Request message for GetShelf method.
message GetShelfRequest {
  // The ID of the shelf resource to retrieve.
  int64 shelf = 1;
}

• option (google.api.http) specifies that this method is a gRPC HTTP mapping annotation.
• get specifies that this method is mapped to an HTTP GET request.
• "/v1/shelves" is the URL path template (appended to your service's domain) that the GET request uses to call this method. The URL path is also known as the resource path because it typically specifies the "thing" or resource you want to use. In this case, all our Bookstore's shelf resources.

details can be found in https://cloud.google.com/endpoints/docs/grpc/transcoding

[tokers]

Yes we could. But in which case we can use it? AFAIK the use case is for bulding a grpc gateway like what etcd did.

Another problem, does it support Lua ecosystem?

[sysulq]

This is a standard protocol which has no relations to specific languages.

The situation is indeed to build a grpc gateway, but we do not need to define any api bussiness related config in the gateway(apisix), but in the protobuf directly. And all we need to do is just to open/close the grpc trancode plugin switch.

Just like what envoy did.

[tokers]

If i understood correctly, we need to refine these APIs from the protobuf and build a route radixtree and match routes further when the grpc-transcode plugin executing but still use HTTP protocol.

It may has some benefits although i can't find any reasons why we need to use HTTP protocol in grpc transcode here. Also, I don't know whether the ecosystem in Lua is complete.

[sysulq]

You're right.

From the user side, like douyu, we strongly need this for better grpc api maintainance :-)

1. do not store protobuf in etcd.
2. do not consider too much api bussiness logic in gateway.
3. just link services to the specific protobuf set in gateway, and everything goes simple.