1---
2category: documentation
3title: FAQ
4---
5
6# FAQ
7
8## How can I write the annotations which grpc-gateway requires?
9The gRPC-Gateway follows the spec of
10[`google.api.HttpRule`](https://github.com/googleapis/googleapis/blob/master/google/api/http.proto),
11so first check out the documentation if it is feasible in the spec.
12
13See also [a past discussion](https://groups.google.com/d/msg/grpc-io/Xqx80hG0D44/VNCDHjeE6pUJ)
14in the grpc-io mailing list.
15
16## I want to support a certain style of HTTP request but the code generated by grpc-gateway does not. How can I support this style?
17See the question above at first.
18
19The gRPC-Gateway is intended to cover 80% of use cases without forcing you to write comprehensive but
20complicated annotations. So the gateway itself does not always cover all the use cases you
21have by design. In other words, the gateway automates typical boring boilerplate mapping
22between gRPC and HTTP/1 communication, but it does not do arbitrarily complex custom mappings for you.
23
24On the other hand, you can still add whatever you want as a middleware which wraps
25[`runtime.ServeMux`](https://pkg.go.dev/github.com/grpc-ecosystem/grpc-gateway/runtime?tab=doc#ServeMux).
26Since `runtime.ServeMux` is just a standard [`http.Handler`](http://golang.org/pkg/http#Handler),
27you can easily write a custom wrapper of `runtime.ServeMux`, leveraged with existing third-party
28libraries in Go.
29e.g. https://github.com/grpc-ecosystem/grpc-gateway/blob/master/examples/internal/gateway/main.go
30
31## My gRPC server is written in (Scala|C++|Ruby|Haskell|....). Is there a (Scala|C++|Ruby|Haskell|....) version of grpc-gateway?
32
33AFAIK, no. But it should not be a big issue because the reverse-proxy which grpc-gateway generates
34usually works as an independent process and communicates with your gRPC server over TCP or a unix-domain socket.
35
36## Why are the models in the swagger specification prefixed with the last part of the proto package name?
37
38The reason to generate the prefixes is that we don't have a guaranteed unique namespace.
39If two packages produce different Foo messages then we will have trouble.
40
41## Why not strip the prefix?
42
43When a message is added which happens to conflict with another message
44(e.g. by importing a message with the same name from a different package)
45it will break code that is very far away from the code that changed.
46This is in an effort to adhere to the
47[principle of least astonishment](https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
View as plain text