Description
In gRPC, you typically have the following format for enums
// MediaVisibility represents the visibility of a media file
enum MediaVisibility {
// The media visibility is not specified
MEDIA_VISIBILITY_UNSPECIFIED = 0;
// The media visibility is public
MEDIA_VISIBILITY_PUBLIC = 1;
// The media visibility is private
MEDIA_VISIBILITY_PRIVATE = 2;
}
You prefix the enum values; otherwise, it crashes on compile if you have identical values on the next enums (e.g UNSPECIFIED)
// Status of a custom domain
enum Status {
// The status is not specified
UNSPECIFIED = 0;
// The domain is inactive. It was created but not checked yet.
INACTIVE = 1;
// The domain is pending. Last time it was checked, it was not pointing to the correct Linkbreakers subdomain.
DOMAIN_PENDING = 2;
// The domain is pending verification. Please verify through TXT record.
VERIFICATION_PENDING = 3;
// The domain is pending certificate. The SSL certificate is not yet ready.
CERTIFICATE_PENDING = 4;
// The domain is fully active
ACTIVE = 5;
}
// Status of a custom domain
enum Something {
// The status is not specified
UNSPECIFIED = 0;
}
This will have the following result
api/v1/custom_domains.proto:309:5:symbol "api.v1.CustomDomain.UNSPECIFIED" already defined at api/v1/custom_domains.proto:293:5; protobuf uses C++ scoping rules for enum values, so they exist in the scope enclosing the enum
make: *** [proto] Error 100
This is fine in gRPC, but upon converting this into HTTP REST you really want to avoid bloating your API with prefixes like this. In my previous example, it's perfect to have PUBLIC and PRIVATE as possible values for REST.
I didn't find any way to do so through your library, and I'm quite surprised nobody has faced this problem. Is everyone just having a prefix on their generated REST APIs?
Also, I'm not sure how to fix this. I'm currently converting a whole API and want to have good standards and avoid the prefix on my REST API for sure, any idea how I could manipulate the gateway to make it work?