Enum prefixes and gRPC Gateway

[Loschcode]

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?

[johanbrandhorst]

Hi Laurent, thanks for your issue. To my knowledge, there isn't any way to avoid this right now. With golang/protobuf#513 (comment) being implemented though, there might be a way forward for this now. I haven't really dug into what we'd need to do or if this even changes the JSON format. If you think we can use this functionality to support stripping the prefix in our JSON parsing, I'd be open to adding an option to support that.

[Loschcode]

Hi Johan,

I appreciate the quick response. For now, I'm personally marshaling/unmarshaling on top of the gateway and using reflection to make it work. Regarding the OpenAPI documentation generation, I stripped the prefix in post-processing.

This is a hack and will not be satisfying long-term, but I had little choice for the task at hand. I haven't checked the edition you're talking about, and it seems something is ongoing indeed, but hasn't been merged yet, if I read that correctly.

Not sure how we can work this out in the future but I'll be happy to help once I understand all of that better.