Transports can vary by API path - or at least, they do in the BUILD.bazel files. This is relatively rare, but any language that bundles multiple API paths together might see this.

I'm seeing it in Python, for the google-cloud-iam library.

Running this in googleapis:

$ grep transport $(find google/iam -name BUILD.bazel) | sort | uniq

gives this output:

google/iam/admin/v1/BUILD.bazel:    transport = "grpc",
google/iam/admin/v1/BUILD.bazel:    transport = "grpc+rest",
google/iam/BUILD.bazel:    transport = "grpc+rest",
google/iam/credentials/BUILD.bazel:    transport = "grpc+rest",
google/iam/credentials/v1/BUILD.bazel:    transport = "grpc+rest",
google/iam/v1beta/BUILD.bazel:    transport = "grpc",
google/iam/v1beta/BUILD.bazel:    transport = "grpc+rest",
google/iam/v1/BUILD.bazel:    transport = "grpc+rest",
google/iam/v1/logging/BUILD.bazel:    transport = "grpc",
google/iam/v2beta/BUILD.bazel:    transport = "grpc",
google/iam/v2beta/BUILD.bazel:    transport = "grpc+rest",
google/iam/v2/BUILD.bazel:    transport = "grpc+rest",
google/iam/v3beta/BUILD.bazel:    transport = "grpc+rest",
google/iam/v3/BUILD.bazel:    transport = "grpc+rest",

That's problematic in terms of:

• Having different values for the same APIs in some cases for different languages. (This suggests to me that it probably supports grpc+rest for everything...)
• Being inconsistent overall
• Logging doesn't have any services anyway, so there's nothing to use a transport...

Next steps:

• Figure out whether we can actually use grpc+rest for all of these
• See if there are other clustered APIs with the same inconsistency
• Support this in the config only if it's actually a problem

Assigning to @zhumin8 as she's heading up config work.