Classes
Advice
Generated advice about this change, used for providing more information about how a change will affect the existing service.
Protobuf type google.api.Advice
Advice.Builder
Generated advice about this change, used for providing more information about how a change will affect the existing service.
Protobuf type google.api.Advice
AnnotationsProto
AuthProto
AuthProvider
Configuration for an authentication provider, including support for JSON Web Token (JWT).
Protobuf type google.api.AuthProvider
AuthProvider.Builder
Configuration for an authentication provider, including support for JSON Web Token (JWT).
Protobuf type google.api.AuthProvider
AuthRequirement
User-defined authentication requirements, including support for JSON Web Token (JWT).
Protobuf type google.api.AuthRequirement
AuthRequirement.Builder
User-defined authentication requirements, including support for JSON Web Token (JWT).
Protobuf type google.api.AuthRequirement
Authentication
Authentication defines the authentication configuration for API methods
provided by an API service.
Example:
name: calendar.googleapis.com
authentication:
providers:
- id: google_calendar_auth jwks_uri: https://www.googleapis.com/oauth2/v1/certs issuer: https://securetoken.google.com rules:
- selector: "*" requirements: provider_id: google_calendar_auth
- selector: google.calendar.Delegate oauth: canonical_scopes: https://www.googleapis.com/auth/calendar.read
Protobuf type google.api.Authentication
Authentication.Builder
Authentication defines the authentication configuration for API methods
provided by an API service.
Example:
name: calendar.googleapis.com
authentication:
providers:
- id: google_calendar_auth jwks_uri: https://www.googleapis.com/oauth2/v1/certs issuer: https://securetoken.google.com rules:
- selector: "*" requirements: provider_id: google_calendar_auth
- selector: google.calendar.Delegate oauth: canonical_scopes: https://www.googleapis.com/auth/calendar.read
Protobuf type google.api.Authentication
AuthenticationRule
Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It's an error to include more than one kind of credential in a single request. If a method doesn't have any auth requirements, request credentials will be ignored.
Protobuf type google.api.AuthenticationRule
AuthenticationRule.Builder
Authentication rules for the service. By default, if a method has any authentication requirements, every request must include a valid credential matching one of the requirements. It's an error to include more than one kind of credential in a single request. If a method doesn't have any auth requirements, request credentials will be ignored.
Protobuf type google.api.AuthenticationRule
Backend
Backend defines the backend configuration for a service.
Protobuf type google.api.Backend
Backend.Builder
Backend defines the backend configuration for a service.
Protobuf type google.api.Backend
BackendProto
BackendRule
A backend rule provides configuration for an individual API element.
Protobuf type google.api.BackendRule
BackendRule.Builder
A backend rule provides configuration for an individual API element.
Protobuf type google.api.BackendRule
Billing
Billing related configuration of the service.
The following example shows how to configure monitored resources and metrics
for billing, consumer_destinations is the only supported destination and
the monitored resources need at least one label key
cloud.googleapis.com/location to indicate the location of the billing
usage, using different monitored resources between monitoring and billing is
recommended so they can be evolved independently:
monitored_resources:
- type: library.googleapis.com/billing_branch
labels:
- key: cloud.googleapis.com/location description: | Predefined label to support billing location restriction.
- key: city description: | Custom label to define the city where the library branch is located in.
- key: name description: Custom label to define the name of the library branch. metrics:
- name: library.googleapis.com/book/borrowed_count
metric_kind: DELTA
value_type: INT64
unit: "1"
billing:
consumer_destinations:
- monitored_resource: library.googleapis.com/billing_branch
metrics:
- library.googleapis.com/book/borrowed_count
- monitored_resource: library.googleapis.com/billing_branch
metrics:
Protobuf type google.api.Billing
Billing.BillingDestination
Configuration of a specific billing destination (Currently only support bill against consumer project).
Protobuf type google.api.Billing.BillingDestination
Billing.BillingDestination.Builder
Configuration of a specific billing destination (Currently only support bill against consumer project).
Protobuf type google.api.Billing.BillingDestination
Billing.Builder
Billing related configuration of the service.
The following example shows how to configure monitored resources and metrics
for billing, consumer_destinations is the only supported destination and
the monitored resources need at least one label key
cloud.googleapis.com/location to indicate the location of the billing
usage, using different monitored resources between monitoring and billing is
recommended so they can be evolved independently:
monitored_resources:
- type: library.googleapis.com/billing_branch
labels:
- key: cloud.googleapis.com/location description: | Predefined label to support billing location restriction.
- key: city description: | Custom label to define the city where the library branch is located in.
- key: name description: Custom label to define the name of the library branch. metrics:
- name: library.googleapis.com/book/borrowed_count
metric_kind: DELTA
value_type: INT64
unit: "1"
billing:
consumer_destinations:
- monitored_resource: library.googleapis.com/billing_branch
metrics:
- library.googleapis.com/book/borrowed_count
- monitored_resource: library.googleapis.com/billing_branch
metrics:
Protobuf type google.api.Billing
BillingProto
ClientProto
ConfigChange
Output generated from semantically comparing two versions of a service configuration. Includes detailed information about a field that have changed with applicable advice about potential consequences for the change, such as backwards-incompatibility.
Protobuf type google.api.ConfigChange
ConfigChange.Builder
Output generated from semantically comparing two versions of a service configuration. Includes detailed information about a field that have changed with applicable advice about potential consequences for the change, such as backwards-incompatibility.
Protobuf type google.api.ConfigChange
ConfigChangeProto
ConsumerProto
Context
Context defines which contexts an API requests.
Example:
context:
rules:
- selector: "*"
requested:
- google.rpc.context.ProjectContext
- google.rpc.context.OriginContext
The above specifies that all methods in the API request
google.rpc.context.ProjectContextandgoogle.rpc.context.OriginContext. Available context types are defined in packagegoogle.rpc.context. This also provides mechanism to allowlist any protobuf message extension that can be sent in grpc metadata using \u201cx-goog-ext-<extension_id>-bin\u201d and \u201cx-goog-ext-<extension_id>-jspb\u201d format. For example, list any service specific protobuf types that can appear in grpc metadata as follows in your yaml file: Example: context: rules: - selector: "google.example.library.v1.LibraryService.CreateBook"
allowed_request_extensions:
- google.foo.v1.NewExtension allowed_response_extensions:
- google.foo.v1.NewExtension You can also specify extension ID instead of fully qualified extension name here.
Protobuf type google.api.Context
Context.Builder
Context defines which contexts an API requests.
Example:
context:
rules:
- selector: "*"
requested:
- google.rpc.context.ProjectContext
- google.rpc.context.OriginContext
The above specifies that all methods in the API request
google.rpc.context.ProjectContextandgoogle.rpc.context.OriginContext. Available context types are defined in packagegoogle.rpc.context. This also provides mechanism to allowlist any protobuf message extension that can be sent in grpc metadata using \u201cx-goog-ext-<extension_id>-bin\u201d and \u201cx-goog-ext-<extension_id>-jspb\u201d format. For example, list any service specific protobuf types that can appear in grpc metadata as follows in your yaml file: Example: context: rules: - selector: "google.example.library.v1.LibraryService.CreateBook"
allowed_request_extensions:
- google.foo.v1.NewExtension allowed_response_extensions:
- google.foo.v1.NewExtension You can also specify extension ID instead of fully qualified extension name here.
Protobuf type google.api.Context
ContextProto
ContextRule
A context rule provides information about the context for an individual API element.
Protobuf type google.api.ContextRule
ContextRule.Builder
A context rule provides information about the context for an individual API element.
Protobuf type google.api.ContextRule
Control
Selects and configures the service controller used by the service. The service controller handles features like abuse, quota, billing, logging, monitoring, etc.
Protobuf type google.api.Control
Control.Builder
Selects and configures the service controller used by the service. The service controller handles features like abuse, quota, billing, logging, monitoring, etc.
Protobuf type google.api.Control
ControlProto
CustomHttpPattern
A custom pattern is used for defining custom HTTP verb.
Protobuf type google.api.CustomHttpPattern
CustomHttpPattern.Builder
A custom pattern is used for defining custom HTTP verb.
Protobuf type google.api.CustomHttpPattern
Distribution
Distribution contains summary statistics for a population of values. It
optionally contains a histogram representing the distribution of those values
across a set of buckets.
The summary statistics are the count, mean, sum of the squared deviation from
the mean, the minimum, and the maximum of the set of population of values.
The histogram is based on a sequence of buckets and gives a count of values
that fall into each bucket. The boundaries of the buckets are given either
explicitly or by formulas for buckets of fixed or exponentially increasing
widths.
Although it is not forbidden, it is generally a bad idea to include
non-finite values (infinities or NaNs) in the population of values, as this
will render the mean and sum_of_squared_deviation fields meaningless.
Protobuf type google.api.Distribution
Distribution.BucketOptions
BucketOptions describes the bucket boundaries used to create a histogram
for the distribution. The buckets can be in a linear sequence, an
exponential sequence, or each bucket can be specified explicitly.
BucketOptions does not include the number of values in each bucket.
A bucket has an inclusive lower bound and exclusive upper bound for the
values that are counted for that bucket. The upper bound of a bucket must
be strictly greater than the lower bound. The sequence of N buckets for a
distribution consists of an underflow bucket (number 0), zero or more
finite buckets (number 1 through N - 2) and an overflow bucket (number N -
1). The buckets are contiguous: the lower bound of bucket i (i > 0) is the
same as the upper bound of bucket i - 1. The buckets span the whole range
of finite values: lower bound of the underflow bucket is -infinity and the
upper bound of the overflow bucket is +infinity. The finite buckets are
so-called because both bounds are finite.
Protobuf type google.api.Distribution.BucketOptions
Distribution.BucketOptions.Builder
BucketOptions describes the bucket boundaries used to create a histogram
for the distribution. The buckets can be in a linear sequence, an
exponential sequence, or each bucket can be specified explicitly.
BucketOptions does not include the number of values in each bucket.
A bucket has an inclusive lower bound and exclusive upper bound for the
values that are counted for that bucket. The upper bound of a bucket must
be strictly greater than the lower bound. The sequence of N buckets for a
distribution consists of an underflow bucket (number 0), zero or more
finite buckets (number 1 through N - 2) and an overflow bucket (number N -
1). The buckets are contiguous: the lower bound of bucket i (i > 0) is the
same as the upper bound of bucket i - 1. The buckets span the whole range
of finite values: lower bound of the underflow bucket is -infinity and the
upper bound of the overflow bucket is +infinity. The finite buckets are
so-called because both bounds are finite.
Protobuf type google.api.Distribution.BucketOptions
Distribution.BucketOptions.Explicit
Specifies a set of buckets with arbitrary widths.
There are size(bounds) + 1 (= N) buckets. Bucket i has the following
boundaries:
Upper bound (0 <= i < N-1): bounds[i]
Lower bound (1 <= i < N); bounds[i - 1]
The bounds field must contain at least one element. If bounds has
only one element, then there are no finite buckets, and that single
element is the common boundary of the overflow and underflow buckets.
Protobuf type google.api.Distribution.BucketOptions.Explicit
Distribution.BucketOptions.Explicit.Builder
Specifies a set of buckets with arbitrary widths.
There are size(bounds) + 1 (= N) buckets. Bucket i has the following
boundaries:
Upper bound (0 <= i < N-1): bounds[i]
Lower bound (1 <= i < N); bounds[i - 1]
The bounds field must contain at least one element. If bounds has
only one element, then there are no finite buckets, and that single
element is the common boundary of the overflow and underflow buckets.
Protobuf type google.api.Distribution.BucketOptions.Explicit
Distribution.BucketOptions.Exponential
Specifies an exponential sequence of buckets that have a width that is
proportional to the value of the lower bound. Each bucket represents a
constant relative uncertainty on a specific value in the bucket.
There are num_finite_buckets + 2 (= N) buckets. Bucket i has the
following boundaries:
Upper bound (0 <= i < N-1): scale * (growth_factor ^ i).
Lower bound (1 <= i < N): scale * (growth_factor ^ (i - 1)).
Protobuf type google.api.Distribution.BucketOptions.Exponential
Distribution.BucketOptions.Exponential.Builder
Specifies an exponential sequence of buckets that have a width that is
proportional to the value of the lower bound. Each bucket represents a
constant relative uncertainty on a specific value in the bucket.
There are num_finite_buckets + 2 (= N) buckets. Bucket i has the
following boundaries:
Upper bound (0 <= i < N-1): scale * (growth_factor ^ i).
Lower bound (1 <= i < N): scale * (growth_factor ^ (i - 1)).
Protobuf type google.api.Distribution.BucketOptions.Exponential
Distribution.BucketOptions.Linear
Specifies a linear sequence of buckets that all have the same width
(except overflow and underflow). Each bucket represents a constant
absolute uncertainty on the specific value in the bucket.
There are num_finite_buckets + 2 (= N) buckets. Bucket i has the
following boundaries:
Upper bound (0 <= i < N-1): offset + (width * i).
Lower bound (1 <= i < N): offset + (width * (i - 1)).
Protobuf type google.api.Distribution.BucketOptions.Linear
Distribution.BucketOptions.Linear.Builder
Specifies a linear sequence of buckets that all have the same width
(except overflow and underflow). Each bucket represents a constant
absolute uncertainty on the specific value in the bucket.
There are num_finite_buckets + 2 (= N) buckets. Bucket i has the
following boundaries:
Upper bound (0 <= i < N-1): offset + (width * i).
Lower bound (1 <= i < N): offset + (width * (i - 1)).
Protobuf type google.api.Distribution.BucketOptions.Linear
Distribution.Builder
Distribution contains summary statistics for a population of values. It
optionally contains a histogram representing the distribution of those values
across a set of buckets.
The summary statistics are the count, mean, sum of the squared deviation from
the mean, the minimum, and the maximum of the set of population of values.
The histogram is based on a sequence of buckets and gives a count of values
that fall into each bucket. The boundaries of the buckets are given either
explicitly or by formulas for buckets of fixed or exponentially increasing
widths.
Although it is not forbidden, it is generally a bad idea to include
non-finite values (infinities or NaNs) in the population of values, as this
will render the mean and sum_of_squared_deviation fields meaningless.
Protobuf type google.api.Distribution
Distribution.Exemplar
Exemplars are example points that may be used to annotate aggregated distribution values. They are metadata that gives information about a particular value added to a Distribution bucket, such as a trace ID that was active when a value was added. They may contain further information, such as a example values and timestamps, origin, etc.
Protobuf type google.api.Distribution.Exemplar
Distribution.Exemplar.Builder
Exemplars are example points that may be used to annotate aggregated distribution values. They are metadata that gives information about a particular value added to a Distribution bucket, such as a trace ID that was active when a value was added. They may contain further information, such as a example values and timestamps, origin, etc.
Protobuf type google.api.Distribution.Exemplar
Distribution.Range
The range of the population values.
Protobuf type google.api.Distribution.Range
Distribution.Range.Builder
The range of the population values.
Protobuf type google.api.Distribution.Range
DistributionProto
Documentation
Documentation provides the information for describing a service.
Example:
<pre><code>documentation:
summary: >
The Google Calendar API gives access
to most calendar features.
pages:
- name: Overview
content: (
include google/foo/overview.md
) - name: Tutorial
content: (
include google/foo/tutorial.md
) subpages;- name: Java
content: (
include google/foo/tutorial_java.md
) rules:
- name: Java
content: (
- selector: google.calendar.Calendar.Get description: > ...
- selector: google.calendar.Calendar.Put
description: >
...
</code></pre>
Documentation is provided in markdown syntax. In addition to
standard markdown features, definition lists, tables and fenced
code blocks are supported. Section headers can be provided and are
interpreted relative to the section nesting of the context where
a documentation fragment is embedded.
Documentation from the IDL is merged with documentation defined
via the config at normalization time, where documentation provided
by config rules overrides IDL provided.
A number of constructs specific to the API platform are supported
in documentation text.
In order to reference a proto element, the following
notation can be used:
<pre><code>[fully.qualified.proto.name][]</code></pre>
To override the display text used for the link, this can be used:
<pre><code>[display text][fully.qualified.proto.name]</code></pre>
Text can be excluded from doc using the following notation:
<pre><code>(-- internal comment --)</code></pre>
A few directives are available in documentation. Note that
directives must appear on a single line to be properly
identified. The
includedirective includes a markdown file from an external source: <pre><code>(include path/to/file
)</code></pre> Theresource_fordirective marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: <pre><code>(resource_for v1.shelves.books
)</code></pre> The directivesuppress_warningdoes not directly affect documentation and is documented together with service config validation.
Protobuf type google.api.Documentation
Documentation.Builder
Documentation provides the information for describing a service.
Example:
<pre><code>documentation:
summary: >
The Google Calendar API gives access
to most calendar features.
pages:
- name: Overview
content: (
include google/foo/overview.md
) - name: Tutorial
content: (
include google/foo/tutorial.md
) subpages;- name: Java
content: (
include google/foo/tutorial_java.md
) rules:
- name: Java
content: (
- selector: google.calendar.Calendar.Get description: > ...
- selector: google.calendar.Calendar.Put
description: >
...
</code></pre>
Documentation is provided in markdown syntax. In addition to
standard markdown features, definition lists, tables and fenced
code blocks are supported. Section headers can be provided and are
interpreted relative to the section nesting of the context where
a documentation fragment is embedded.
Documentation from the IDL is merged with documentation defined
via the config at normalization time, where documentation provided
by config rules overrides IDL provided.
A number of constructs specific to the API platform are supported
in documentation text.
In order to reference a proto element, the following
notation can be used:
<pre><code>[fully.qualified.proto.name][]</code></pre>
To override the display text used for the link, this can be used:
<pre><code>[display text][fully.qualified.proto.name]</code></pre>
Text can be excluded from doc using the following notation:
<pre><code>(-- internal comment --)</code></pre>
A few directives are available in documentation. Note that
directives must appear on a single line to be properly
identified. The
includedirective includes a markdown file from an external source: <pre><code>(include path/to/file
)</code></pre> Theresource_fordirective marks a message to be the resource of a collection in REST view. If it is not specified, tools attempt to infer the resource from the operations in a collection: <pre><code>(resource_for v1.shelves.books
)</code></pre> The directivesuppress_warningdoes not directly affect documentation and is documented together with service config validation.
Protobuf type google.api.Documentation
DocumentationProto
DocumentationRule
A documentation rule provides information about individual API elements.
Protobuf type google.api.DocumentationRule
DocumentationRule.Builder
A documentation rule provides information about individual API elements.
Protobuf type google.api.DocumentationRule
Endpoint
Endpoint describes a network endpoint of a service that serves a set of
APIs. It is commonly known as a service endpoint. A service may expose
any number of service endpoints, and all service endpoints share the same
service definition, such as quota limits and monitoring metrics.
Example service configuration:
name: library-example.googleapis.com
endpoints:
Below entry makes 'google.example.library.v1.Library'
# API be served from endpoint address library-example.googleapis.com.
# It also allows HTTP OPTIONS calls to be passed to the backend, for
# it to decide whether the subsequent cross-origin request is
# allowed to proceed.
- name: library-example.googleapis.com
allow_cors: true
Protobuf type google.api.Endpoint
Endpoint.Builder
Endpoint describes a network endpoint of a service that serves a set of
APIs. It is commonly known as a service endpoint. A service may expose
any number of service endpoints, and all service endpoints share the same
service definition, such as quota limits and monitoring metrics.
Example service configuration:
name: library-example.googleapis.com
endpoints:
Below entry makes 'google.example.library.v1.Library'
# API be served from endpoint address library-example.googleapis.com.
# It also allows HTTP OPTIONS calls to be passed to the backend, for
# it to decide whether the subsequent cross-origin request is
# allowed to proceed.
- name: library-example.googleapis.com
allow_cors: true
Protobuf type google.api.Endpoint
EndpointProto
ErrorReasonProto
FieldBehaviorProto
Http
Defines the HTTP configuration for an API service. It contains a list of HttpRule, each specifying the mapping of an RPC method to one or more HTTP REST API methods.
Protobuf type google.api.Http
Http.Builder
Defines the HTTP configuration for an API service. It contains a list of HttpRule, each specifying the mapping of an RPC method to one or more HTTP REST API methods.
Protobuf type google.api.Http
HttpBody
Message that represents an arbitrary HTTP body. It should only be used for payload formats that can't be represented as JSON, such as raw binary or an HTML page. This message can be used both in streaming and non-streaming API methods in the request as well as the response. It can be used as a top-level request field, which is convenient if one wants to extract parameters from either the URL or HTTP template into the request fields and also want access to the raw HTTP body. Example: message GetResourceRequest { // A unique request id. string request_id = 1; // The raw HTTP body is bound to this field. google.api.HttpBody http_body = 2; } service ResourceService { rpc GetResource(GetResourceRequest) returns (google.api.HttpBody); rpc UpdateResource(google.api.HttpBody) returns (google.protobuf.Empty); } Example with streaming methods: service CaldavService { rpc GetCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); rpc UpdateCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); } Use of this type only changes how the request and response bodies are handled, all other features will continue to work unchanged.
Protobuf type google.api.HttpBody
HttpBody.Builder
Message that represents an arbitrary HTTP body. It should only be used for payload formats that can't be represented as JSON, such as raw binary or an HTML page. This message can be used both in streaming and non-streaming API methods in the request as well as the response. It can be used as a top-level request field, which is convenient if one wants to extract parameters from either the URL or HTTP template into the request fields and also want access to the raw HTTP body. Example: message GetResourceRequest { // A unique request id. string request_id = 1; // The raw HTTP body is bound to this field. google.api.HttpBody http_body = 2; } service ResourceService { rpc GetResource(GetResourceRequest) returns (google.api.HttpBody); rpc UpdateResource(google.api.HttpBody) returns (google.protobuf.Empty); } Example with streaming methods: service CaldavService { rpc GetCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); rpc UpdateCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); } Use of this type only changes how the request and response bodies are handled, all other features will continue to work unchanged.
Protobuf type google.api.HttpBody
HttpBodyProto
HttpProto
HttpRule
gRPC Transcoding
gRPC Transcoding is a feature for mapping between a gRPC method and one or
more HTTP REST endpoints. It allows developers to build a single API service
that supports both gRPC APIs and REST APIs. Many systems, including Google
APIs,
Cloud Endpoints, gRPC
Gateway,
and Envoy proxy support this feature
and use it for large scale production services.
HttpRule defines the schema of the gRPC/REST mapping. The mapping specifies
how different portions of the gRPC request message are mapped to the URL
path, URL query parameters, and HTTP request body. It also controls how the
gRPC response message is mapped to the HTTP response body. HttpRule is
typically specified as an google.api.http annotation on the gRPC method.
Each mapping specifies a URL path template and an HTTP method. The path
template may refer to one or more fields in the gRPC request message, as long
as each field is a non-repeated field with a primitive (non-message) type.
The path template controls how fields of the request message are mapped to
the URL path.
Example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get: "/v1/{name=messages/*}"
};
}
}
message GetMessageRequest {
string name = 1; // Mapped to URL path.
}
message Message {
string text = 1; // The resource content.
}
This enables an HTTP REST to gRPC mapping as below:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456 | GetMessage(name: "messages/123456") |
Any fields in the request message which are not bound by the path template
automatically become HTTP query parameters if there is no HTTP request body.
For example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get:"/v1/messages/{message_id}"
};
}
}
message GetMessageRequest {
message SubMessage {
string subfield = 1;
}
string message_id = 1; // Mapped to URL path.
int64 revision = 2; // Mapped to URL query parameter revision.
SubMessage sub = 3; // Mapped to URL query parameter sub.subfield.
}
This enables a HTTP JSON to RPC mapping as below:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456?revision=2&sub.subfield=foo |
GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield:
"foo"))
Note that fields which are mapped to URL query parameters must have a
primitive type or a repeated primitive type or a non-repeated message type.
In the case of a repeated type, the parameter can be repeated in the URL
as ...?param=A¶m=B. In the case of a message type, each field of the
message is mapped to a separate parameter, such as
...?foo.a=A&foo.b=B&foo.c=C.
For HTTP methods that allow a request body, the body field
specifies the mapping. Consider a REST update method on the
message resource collection:
service Messaging {
rpc UpdateMessage(UpdateMessageRequest) returns (Message) {
option (google.api.http) = {
patch: "/v1/messages/{message_id}"
body: "message"
};
}
}
message UpdateMessageRequest {
string message_id = 1; // mapped to the URL
Message message = 2; // mapped to the body
}
The following HTTP JSON to RPC mapping is enabled, where the
representation of the JSON in the request body is determined by
protos JSON encoding:
| HTTP | gRPC |
|---|---|
PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: |
"123456" message { text: "Hi!" })
The special name can be used in the body mapping to define that
every field not bound by the path template should be mapped to the
request body. This enables the following alternative definition of
the update method:
service Messaging {
rpc UpdateMessage(Message) returns (Message) {
option (google.api.http) = {
patch: "/v1/messages/{message_id}"
body: ""
};
}
}
message Message {
string message_id = 1;
string text = 2;
}
The following HTTP JSON to RPC mapping is enabled:
| HTTP | gRPC |
|---|---|
PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: |
"123456" text: "Hi!")
Note that when using in the body mapping, it is not possible to
have HTTP parameters, as all fields not bound by the path end in
the body. This makes this option more rarely used in practice when
defining REST APIs. The common usage of is in custom methods
which don't use the URL at all for transferring data.
It is possible to define multiple HTTP methods for one RPC by using
the additional_bindings option. Example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get: "/v1/messages/{message_id}"
additional_bindings {
get: "/v1/users/{user_id}/messages/{message_id}"
}
};
}
}
message GetMessageRequest {
string message_id = 1;
string user_id = 2;
}
This enables the following two alternative HTTP JSON to RPC mappings:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456 | GetMessage(message_id: "123456") |
GET /v1/users/me/messages/123456 | GetMessage(user_id: "me" message_id: |
"123456")
Rules for HTTP mapping
- Leaf request fields (recursive expansion nested messages in the request
message) are classified into three categories:
- Fields referred by the path template. They are passed via the URL path.
- Fields referred by the HttpRule.body. They are passed via the HTTP request body.
- All other fields are passed via the URL query parameters, and the parameter name is the field path in the request message. A repeated field can be represented as multiple query parameters under the same name.
- If HttpRule.body is "*", there is no URL query parameter, all fields are passed via URL path and HTTP request body.
- If HttpRule.body is omitted, there is no HTTP request body, all
fields are passed via URL path and URL query parameters.
### Path template syntax
Template = "/" Segments [ Verb ] ;
Segments = Segment { "/" Segment } ;
Segment = "" | "" | LITERAL | Variable ;
Variable = "{" FieldPath [ "=" Segments ] "}" ;
FieldPath = IDENT { "." IDENT } ;
Verb = ":" LITERAL ;
The syntax
matches a single URL path segment. The syntaxmatches zero or more URL path segments, which must be the last part of the URL path except theVerb. The syntaxVariablematches part of the URL path as specified by its template. A variable template must not contain other variables. If a variable matches a single path segment, its template may be omitted, e.g.{var}is equivalent to{var=}. The syntaxLITERALmatches literal text in the URL path. If theLITERALcontains any reserved character, such characters should be percent-encoded before the matching. If a variable contains exactly one path segment, such as"{var}"or"{var=}", when such a variable is expanded into a URL path on the client side, all characters except[-_.~0-9a-zA-Z]are percent-encoded. The server side does the reverse decoding. Such variables show up in the Discovery Document as{var}. If a variable contains multiple path segments, such as"{var=foo/*}"or"{var=}", when such a variable is expanded into a URL path on the client side, all characters except[-_.~/0-9a-zA-Z]are percent-encoded. The server side does the reverse decoding, except "%2F" and "%2f" are left unchanged. Such variables show up in the Discovery Document as{+var}. ## Using gRPC API Service Configuration gRPC API Service Configuration (service config) is a configuration language for configuring a gRPC service to become a user-facing product. The service config is simply the YAML representation of thegoogle.api.Serviceproto message. As an alternative to annotating your proto file, you can configure gRPC transcoding in your service config YAML files. You do this by specifying aHttpRulethat maps the gRPC method to a REST endpoint, achieving the same effect as the proto annotation. This can be particularly useful if you have a proto that is reused in multiple services. Note that any transcoding specified in the service config will override any matching transcoding configuration in the proto. Example: http: rules: # Selects a gRPC method and applies HttpRule to it.- selector: example.v1.Messaging.GetMessage
get: /v1/messages/{message_id}/{sub.subfield}
## Special notes
When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the
proto to JSON conversion must follow the proto3
specification.
While the single segment variable follows the semantics of
RFC 6570 Section 3.2.2 Simple String
Expansion, the multi segment variable does not follow RFC 6570 Section
3.2.3 Reserved Expansion. The reason is that the Reserved Expansion
does not expand special characters like
?and#, which would lead to invalid URLs. As the result, gRPC Transcoding uses a custom encoding for multi segment variables. The path variables must not refer to any repeated or mapped field, because client libraries are not capable of handling such variable expansion. The path variables must not capture the leading "/" character. The reason is that the most common use case "{var}" does not capture the leading "/" character. For consistency, all path variables must share the same behavior. Repeated message fields must not be mapped to URL query parameters, because no client library can support such complicated mapping. If an API needs to use a JSON array for request or response body, it can map the request or response body to a repeated field. However, some gRPC Transcoding implementations may not support this feature.
- selector: example.v1.Messaging.GetMessage
get: /v1/messages/{message_id}/{sub.subfield}
## Special notes
When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the
proto to JSON conversion must follow the proto3
specification.
While the single segment variable follows the semantics of
RFC 6570 Section 3.2.2 Simple String
Expansion, the multi segment variable does not follow RFC 6570 Section
3.2.3 Reserved Expansion. The reason is that the Reserved Expansion
does not expand special characters like
Protobuf type google.api.HttpRule
HttpRule.Builder
gRPC Transcoding
gRPC Transcoding is a feature for mapping between a gRPC method and one or
more HTTP REST endpoints. It allows developers to build a single API service
that supports both gRPC APIs and REST APIs. Many systems, including Google
APIs,
Cloud Endpoints, gRPC
Gateway,
and Envoy proxy support this feature
and use it for large scale production services.
HttpRule defines the schema of the gRPC/REST mapping. The mapping specifies
how different portions of the gRPC request message are mapped to the URL
path, URL query parameters, and HTTP request body. It also controls how the
gRPC response message is mapped to the HTTP response body. HttpRule is
typically specified as an google.api.http annotation on the gRPC method.
Each mapping specifies a URL path template and an HTTP method. The path
template may refer to one or more fields in the gRPC request message, as long
as each field is a non-repeated field with a primitive (non-message) type.
The path template controls how fields of the request message are mapped to
the URL path.
Example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get: "/v1/{name=messages/*}"
};
}
}
message GetMessageRequest {
string name = 1; // Mapped to URL path.
}
message Message {
string text = 1; // The resource content.
}
This enables an HTTP REST to gRPC mapping as below:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456 | GetMessage(name: "messages/123456") |
Any fields in the request message which are not bound by the path template
automatically become HTTP query parameters if there is no HTTP request body.
For example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get:"/v1/messages/{message_id}"
};
}
}
message GetMessageRequest {
message SubMessage {
string subfield = 1;
}
string message_id = 1; // Mapped to URL path.
int64 revision = 2; // Mapped to URL query parameter revision.
SubMessage sub = 3; // Mapped to URL query parameter sub.subfield.
}
This enables a HTTP JSON to RPC mapping as below:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456?revision=2&sub.subfield=foo |
GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield:
"foo"))
Note that fields which are mapped to URL query parameters must have a
primitive type or a repeated primitive type or a non-repeated message type.
In the case of a repeated type, the parameter can be repeated in the URL
as ...?param=A¶m=B. In the case of a message type, each field of the
message is mapped to a separate parameter, such as
...?foo.a=A&foo.b=B&foo.c=C.
For HTTP methods that allow a request body, the body field
specifies the mapping. Consider a REST update method on the
message resource collection:
service Messaging {
rpc UpdateMessage(UpdateMessageRequest) returns (Message) {
option (google.api.http) = {
patch: "/v1/messages/{message_id}"
body: "message"
};
}
}
message UpdateMessageRequest {
string message_id = 1; // mapped to the URL
Message message = 2; // mapped to the body
}
The following HTTP JSON to RPC mapping is enabled, where the
representation of the JSON in the request body is determined by
protos JSON encoding:
| HTTP | gRPC |
|---|---|
PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: |
"123456" message { text: "Hi!" })
The special name can be used in the body mapping to define that
every field not bound by the path template should be mapped to the
request body. This enables the following alternative definition of
the update method:
service Messaging {
rpc UpdateMessage(Message) returns (Message) {
option (google.api.http) = {
patch: "/v1/messages/{message_id}"
body: ""
};
}
}
message Message {
string message_id = 1;
string text = 2;
}
The following HTTP JSON to RPC mapping is enabled:
| HTTP | gRPC |
|---|---|
PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: |
"123456" text: "Hi!")
Note that when using in the body mapping, it is not possible to
have HTTP parameters, as all fields not bound by the path end in
the body. This makes this option more rarely used in practice when
defining REST APIs. The common usage of is in custom methods
which don't use the URL at all for transferring data.
It is possible to define multiple HTTP methods for one RPC by using
the additional_bindings option. Example:
service Messaging {
rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = {
get: "/v1/messages/{message_id}"
additional_bindings {
get: "/v1/users/{user_id}/messages/{message_id}"
}
};
}
}
message GetMessageRequest {
string message_id = 1;
string user_id = 2;
}
This enables the following two alternative HTTP JSON to RPC mappings:
| HTTP | gRPC |
|---|---|
GET /v1/messages/123456 | GetMessage(message_id: "123456") |
GET /v1/users/me/messages/123456 | GetMessage(user_id: "me" message_id: |
"123456")
Rules for HTTP mapping
- Leaf request fields (recursive expansion nested messages in the request
message) are classified into three categories:
- Fields referred by the path template. They are passed via the URL path.
- Fields referred by the HttpRule.body. They are passed via the HTTP request body.
- All other fields are passed via the URL query parameters, and the parameter name is the field path in the request message. A repeated field can be represented as multiple query parameters under the same name.
- If HttpRule.body is "*", there is no URL query parameter, all fields are passed via URL path and HTTP request body.
- If HttpRule.body is omitted, there is no HTTP request body, all
fields are passed via URL path and URL query parameters.
### Path template syntax
Template = "/" Segments [ Verb ] ;
Segments = Segment { "/" Segment } ;
Segment = "" | "" | LITERAL | Variable ;
Variable = "{" FieldPath [ "=" Segments ] "}" ;
FieldPath = IDENT { "." IDENT } ;
Verb = ":" LITERAL ;
The syntax
matches a single URL path segment. The syntaxmatches zero or more URL path segments, which must be the last part of the URL path except theVerb. The syntaxVariablematches part of the URL path as specified by its template. A variable template must not contain other variables. If a variable matches a single path segment, its template may be omitted, e.g.{var}is equivalent to{var=}. The syntaxLITERALmatches literal text in the URL path. If theLITERALcontains any reserved character, such characters should be percent-encoded before the matching. If a variable contains exactly one path segment, such as"{var}"or"{var=}", when such a variable is expanded into a URL path on the client side, all characters except[-_.~0-9a-zA-Z]are percent-encoded. The server side does the reverse decoding. Such variables show up in the Discovery Document as{var}. If a variable contains multiple path segments, such as"{var=foo/*}"or"{var=}", when such a variable is expanded into a URL path on the client side, all characters except[-_.~/0-9a-zA-Z]are percent-encoded. The server side does the reverse decoding, except "%2F" and "%2f" are left unchanged. Such variables show up in the Discovery Document as{+var}. ## Using gRPC API Service Configuration gRPC API Service Configuration (service config) is a configuration language for configuring a gRPC service to become a user-facing product. The service config is simply the YAML representation of thegoogle.api.Serviceproto message. As an alternative to annotating your proto file, you can configure gRPC transcoding in your service config YAML files. You do this by specifying aHttpRulethat maps the gRPC method to a REST endpoint, achieving the same effect as the proto annotation. This can be particularly useful if you have a proto that is reused in multiple services. Note that any transcoding specified in the service config will override any matching transcoding configuration in the proto. Example: http: rules: # Selects a gRPC method and applies HttpRule to it.- selector: example.v1.Messaging.GetMessage
get: /v1/messages/{message_id}/{sub.subfield}
## Special notes
When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the
proto to JSON conversion must follow the proto3
specification.
While the single segment variable follows the semantics of
RFC 6570 Section 3.2.2 Simple String
Expansion, the multi segment variable does not follow RFC 6570 Section
3.2.3 Reserved Expansion. The reason is that the Reserved Expansion
does not expand special characters like
?and#, which would lead to invalid URLs. As the result, gRPC Transcoding uses a custom encoding for multi segment variables. The path variables must not refer to any repeated or mapped field, because client libraries are not capable of handling such variable expansion. The path variables must not capture the leading "/" character. The reason is that the most common use case "{var}" does not capture the leading "/" character. For consistency, all path variables must share the same behavior. Repeated message fields must not be mapped to URL query parameters, because no client library can support such complicated mapping. If an API needs to use a JSON array for request or response body, it can map the request or response body to a repeated field. However, some gRPC Transcoding implementations may not support this feature.
- selector: example.v1.Messaging.GetMessage
get: /v1/messages/{message_id}/{sub.subfield}
## Special notes
When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the
proto to JSON conversion must follow the proto3
specification.
While the single segment variable follows the semantics of
RFC 6570 Section 3.2.2 Simple String
Expansion, the multi segment variable does not follow RFC 6570 Section
3.2.3 Reserved Expansion. The reason is that the Reserved Expansion
does not expand special characters like
Protobuf type google.api.HttpRule
JwtLocation
Specifies a location to extract JWT from an API request.
Protobuf type google.api.JwtLocation
JwtLocation.Builder
Specifies a location to extract JWT from an API request.
Protobuf type google.api.JwtLocation
LabelDescriptor
A description of a label.
Protobuf type google.api.LabelDescriptor
LabelDescriptor.Builder
A description of a label.
Protobuf type google.api.LabelDescriptor
LabelProto
LaunchStageProto
LogDescriptor
A description of a log type. Example in YAML format:
- name: library.googleapis.com/activity_history
description: The history of borrowing and returning library items.
display_name: Activity
labels:
- key: /customer_id description: Identifier of a library customer
Protobuf type google.api.LogDescriptor
LogDescriptor.Builder
A description of a log type. Example in YAML format:
- name: library.googleapis.com/activity_history
description: The history of borrowing and returning library items.
display_name: Activity
labels:
- key: /customer_id description: Identifier of a library customer
Protobuf type google.api.LogDescriptor
LogProto
Logging
Logging configuration of the service.
The following example shows how to configure logs to be sent to the
producer and consumer projects. In the example, the activity_history
log is sent to both the producer and consumer projects, whereas the
purchase_history log is only sent to the producer project.
monitored_resources:
- type: library.googleapis.com/branch
labels:
- key: /city description: The city where the library branch is located in.
- key: /name description: The name of the branch. logs:
- name: activity_history
labels:
- key: /customer_id
- name: purchase_history
logging:
producer_destinations:
- monitored_resource: library.googleapis.com/branch
logs:
- activity_history
- purchase_history consumer_destinations:
- monitored_resource: library.googleapis.com/branch
logs:
- activity_history
- monitored_resource: library.googleapis.com/branch
logs:
Protobuf type google.api.Logging
Logging.Builder
Logging configuration of the service.
The following example shows how to configure logs to be sent to the
producer and consumer projects. In the example, the activity_history
log is sent to both the producer and consumer projects, whereas the
purchase_history log is only sent to the producer project.
monitored_resources:
- type: library.googleapis.com/branch
labels:
- key: /city description: The city where the library branch is located in.
- key: /name description: The name of the branch. logs:
- name: activity_history
labels:
- key: /customer_id
- name: purchase_history
logging:
producer_destinations:
- monitored_resource: library.googleapis.com/branch
logs:
- activity_history
- purchase_history consumer_destinations:
- monitored_resource: library.googleapis.com/branch
logs:
- activity_history
- monitored_resource: library.googleapis.com/branch
logs:
Protobuf type google.api.Logging
Logging.LoggingDestination
Configuration of a specific logging destination (the producer project or the consumer project).
Protobuf type google.api.Logging.LoggingDestination
Logging.LoggingDestination.Builder
Configuration of a specific logging destination (the producer project or the consumer project).
Protobuf type google.api.Logging.LoggingDestination
LoggingProto
Metric
A specific metric, identified by specifying values for all of the
labels of a MetricDescriptor.
Protobuf type google.api.Metric
Metric.Builder
A specific metric, identified by specifying values for all of the
labels of a MetricDescriptor.
Protobuf type google.api.Metric
MetricDescriptor
Defines a metric type and its schema. Once a metric descriptor is created, deleting or altering it stops data collection and makes the metric type's existing data unusable.
Protobuf type google.api.MetricDescriptor
MetricDescriptor.Builder
Defines a metric type and its schema. Once a metric descriptor is created, deleting or altering it stops data collection and makes the metric type's existing data unusable.
Protobuf type google.api.MetricDescriptor
MetricDescriptor.MetricDescriptorMetadata
Additional annotations that can be used to guide the usage of a metric.
Protobuf type google.api.MetricDescriptor.MetricDescriptorMetadata
MetricDescriptor.MetricDescriptorMetadata.Builder
Additional annotations that can be used to guide the usage of a metric.
Protobuf type google.api.MetricDescriptor.MetricDescriptorMetadata
MetricProto
MetricRule
Bind API methods to metrics. Binding a method to a metric causes that metric's configured quota behaviors to apply to the method call.
Protobuf type google.api.MetricRule
MetricRule.Builder
Bind API methods to metrics. Binding a method to a metric causes that metric's configured quota behaviors to apply to the method call.
Protobuf type google.api.MetricRule
MonitoredResource
An object representing a resource that can be used for monitoring, logging,
billing, or other purposes. Examples include virtual machine instances,
databases, and storage devices such as disks. The type field identifies a
MonitoredResourceDescriptor object that describes the resource's
schema. Information in the labels field identifies the actual resource and
its attributes according to the schema. For example, a particular Compute
Engine VM instance could be represented by the following object, because the
MonitoredResourceDescriptor for "gce_instance" has labels
"instance_id" and "zone":
{ "type": "gce_instance",
"labels": { "instance_id": "12345678901234",
"zone": "us-central1-a" }}
Protobuf type google.api.MonitoredResource
MonitoredResource.Builder
An object representing a resource that can be used for monitoring, logging,
billing, or other purposes. Examples include virtual machine instances,
databases, and storage devices such as disks. The type field identifies a
MonitoredResourceDescriptor object that describes the resource's
schema. Information in the labels field identifies the actual resource and
its attributes according to the schema. For example, a particular Compute
Engine VM instance could be represented by the following object, because the
MonitoredResourceDescriptor for "gce_instance" has labels
"instance_id" and "zone":
{ "type": "gce_instance",
"labels": { "instance_id": "12345678901234",
"zone": "us-central1-a" }}
Protobuf type google.api.MonitoredResource
MonitoredResourceDescriptor
An object that describes the schema of a MonitoredResource object using a
type name and a set of labels. For example, the monitored resource
descriptor for Google Compute Engine VM instances has a type of
"gce_instance" and specifies the use of the labels "instance_id" and
"zone" to identify particular VM instances.
Different APIs can support different monitored resource types. APIs generally
provide a list method that returns the monitored resource descriptors used
by the API.
Protobuf type google.api.MonitoredResourceDescriptor
MonitoredResourceDescriptor.Builder
An object that describes the schema of a MonitoredResource object using a
type name and a set of labels. For example, the monitored resource
descriptor for Google Compute Engine VM instances has a type of
"gce_instance" and specifies the use of the labels "instance_id" and
"zone" to identify particular VM instances.
Different APIs can support different monitored resource types. APIs generally
provide a list method that returns the monitored resource descriptors used
by the API.
Protobuf type google.api.MonitoredResourceDescriptor
MonitoredResourceMetadata
Auxiliary metadata for a MonitoredResource object. MonitoredResource objects contain the minimum set of information to uniquely identify a monitored resource instance. There is some other useful auxiliary metadata. Monitoring and Logging use an ingestion pipeline to extract metadata for cloud resources of all types, and store the metadata in this message.
Protobuf type google.api.MonitoredResourceMetadata
MonitoredResourceMetadata.Builder
Auxiliary metadata for a MonitoredResource object. MonitoredResource objects contain the minimum set of information to uniquely identify a monitored resource instance. There is some other useful auxiliary metadata. Monitoring and Logging use an ingestion pipeline to extract metadata for cloud resources of all types, and store the metadata in this message.
Protobuf type google.api.MonitoredResourceMetadata
MonitoredResourceProto
Monitoring
Monitoring configuration of the service.
The example below shows how to configure monitored resources and metrics
for monitoring. In the example, a monitored resource and two metrics are
defined. The library.googleapis.com/book/returned_count metric is sent
to both producer and consumer projects, whereas the
library.googleapis.com/book/num_overdue metric is only sent to the
consumer project.
monitored_resources:
- type: library.googleapis.com/Branch
display_name: "Library Branch"
description: "A branch of a library."
launch_stage: GA
labels:
- key: resource_container description: "The Cloud container (ie. project id) for the Branch."
- key: location description: "The location of the library branch."
- key: branch_id description: "The id of the branch." metrics:
- name: library.googleapis.com/book/returned_count
display_name: "Books Returned"
description: "The count of books that have been returned."
launch_stage: GA
metric_kind: DELTA
value_type: INT64
unit: "1"
labels:
- key: customer_id description: "The id of the customer."
- name: library.googleapis.com/book/num_overdue
display_name: "Books Overdue"
description: "The current number of overdue books."
launch_stage: GA
metric_kind: GAUGE
value_type: INT64
unit: "1"
labels:
- key: customer_id description: "The id of the customer." monitoring: producer_destinations:
- monitored_resource: library.googleapis.com/Branch
metrics:
- library.googleapis.com/book/returned_count consumer_destinations:
- monitored_resource: library.googleapis.com/Branch
metrics:
- library.googleapis.com/book/returned_count
- library.googleapis.com/book/num_overdue
Protobuf type google.api.Monitoring
Monitoring.Builder
Monitoring configuration of the service.
The example below shows how to configure monitored resources and metrics
for monitoring. In the example, a monitored resource and two metrics are
defined. The library.googleapis.com/book/returned_count metric is sent
to both producer and consumer projects, whereas the
library.googleapis.com/book/num_overdue metric is only sent to the
consumer project.
monitored_resources:
- type: library.googleapis.com/Branch
display_name: "Library Branch"
description: "A branch of a library."
launch_stage: GA
labels:
- key: resource_container description: "The Cloud container (ie. project id) for the Branch."
- key: location description: "The location of the library branch."
- key: branch_id description: "The id of the branch." metrics:
- name: library.googleapis.com/book/returned_count
display_name: "Books Returned"
description: "The count of books that have been returned."
launch_stage: GA
metric_kind: DELTA
value_type: INT64
unit: "1"
labels:
- key: customer_id description: "The id of the customer."
- name: library.googleapis.com/book/num_overdue
display_name: "Books Overdue"
description: "The current number of overdue books."
launch_stage: GA
metric_kind: GAUGE
value_type: INT64
unit: "1"
labels:
- key: customer_id description: "The id of the customer." monitoring: producer_destinations:
- monitored_resource: library.googleapis.com/Branch
metrics:
- library.googleapis.com/book/returned_count consumer_destinations:
- monitored_resource: library.googleapis.com/Branch
metrics:
- library.googleapis.com/book/returned_count
- library.googleapis.com/book/num_overdue
Protobuf type google.api.Monitoring
Monitoring.MonitoringDestination
Configuration of a specific monitoring destination (the producer project or the consumer project).
Protobuf type google.api.Monitoring.MonitoringDestination
Monitoring.MonitoringDestination.Builder
Configuration of a specific monitoring destination (the producer project or the consumer project).
Protobuf type google.api.Monitoring.MonitoringDestination
MonitoringProto
OAuthRequirements
OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for "Read-only access to Google Calendar" and "Access to Cloud Platform". Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions.
Protobuf type google.api.OAuthRequirements
OAuthRequirements.Builder
OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for "Read-only access to Google Calendar" and "Access to Cloud Platform". Users can consent to a scope for an application, giving it permission to access that data on their behalf. OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means. In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs. When you need finer grained OAuth consent screens: talk with your product management about how developers will use them in practice. Please note that even though each of the canonical scopes is enough for a request to be accepted and passed to the backend, a request can still fail due to the backend requiring additional scopes or permissions.
Protobuf type google.api.OAuthRequirements
Page
Represents a documentation page. A page can contain subpages to represent nested documentation set structure.
Protobuf type google.api.Page
Page.Builder
Represents a documentation page. A page can contain subpages to represent nested documentation set structure.
Protobuf type google.api.Page
ProjectProperties
A descriptor for defining project properties for a service. One service may have many consumer projects, and the service may want to behave differently depending on some properties on the project. For example, a project may be associated with a school, or a business, or a government agency, a business type property on the project may affect how a service responds to the client. This descriptor defines which properties are allowed to be set on a project. Example: project_properties: properties:
- name: NO_WATERMARK type: BOOL description: Allows usage of the API without watermarks.
- name: EXTENDED_TILE_CACHE_PERIOD type: INT64
Protobuf type google.api.ProjectProperties
ProjectProperties.Builder
A descriptor for defining project properties for a service. One service may have many consumer projects, and the service may want to behave differently depending on some properties on the project. For example, a project may be associated with a school, or a business, or a government agency, a business type property on the project may affect how a service responds to the client. This descriptor defines which properties are allowed to be set on a project. Example: project_properties: properties:
- name: NO_WATERMARK type: BOOL description: Allows usage of the API without watermarks.
- name: EXTENDED_TILE_CACHE_PERIOD type: INT64
Protobuf type google.api.ProjectProperties
Property
Defines project properties. API services can define properties that can be assigned to consumer projects so that backends can perform response customization without having to make additional calls or maintain additional storage. For example, Maps API defines properties that controls map tile cache period, or whether to embed a watermark in a result. These values can be set via API producer console. Only API providers can define and set these properties.
Protobuf type google.api.Property
Property.Builder
Defines project properties. API services can define properties that can be assigned to consumer projects so that backends can perform response customization without having to make additional calls or maintain additional storage. For example, Maps API defines properties that controls map tile cache period, or whether to embed a watermark in a result. These values can be set via API producer console. Only API providers can define and set these properties.
Protobuf type google.api.Property
Quota
Quota configuration helps to achieve fairness and budgeting in service usage. The metric based quota configuration works this way:
- The service configuration defines a set of metrics.
- For API calls, the quota.metric_rules maps methods to metrics with corresponding costs.
- The quota.limits defines limits on the metrics, which will be used for
quota checks at runtime.
An example quota configuration in yaml format:
quota:
limits:
- name: apiWriteQpsPerProject metric: library.googleapis.com/write_calls unit: "1/min/{project}" # rate limit for consumer projects values: STANDARD: 10000 # The metric rules bind all methods to the read_calls metric, # except for the UpdateBook and DeleteBook methods. These two methods # are mapped to the write_calls metric, with the UpdateBook method # consuming at twice rate as the DeleteBook method. metric_rules:
- selector: "*" metric_costs: library.googleapis.com/read_calls: 1
- selector: google.example.library.v1.LibraryService.UpdateBook metric_costs: library.googleapis.com/write_calls: 2
- selector: google.example.library.v1.LibraryService.DeleteBook metric_costs: library.googleapis.com/write_calls: 1 Corresponding Metric definition: metrics:
- name: library.googleapis.com/read_calls display_name: Read requests metric_kind: DELTA value_type: INT64
- name: library.googleapis.com/write_calls display_name: Write requests metric_kind: DELTA value_type: INT64
Protobuf type google.api.Quota
Quota.Builder
Quota configuration helps to achieve fairness and budgeting in service usage. The metric based quota configuration works this way:
- The service configuration defines a set of metrics.
- For API calls, the quota.metric_rules maps methods to metrics with corresponding costs.
- The quota.limits defines limits on the metrics, which will be used for
quota checks at runtime.
An example quota configuration in yaml format:
quota:
limits:
- name: apiWriteQpsPerProject metric: library.googleapis.com/write_calls unit: "1/min/{project}" # rate limit for consumer projects values: STANDARD: 10000 # The metric rules bind all methods to the read_calls metric, # except for the UpdateBook and DeleteBook methods. These two methods # are mapped to the write_calls metric, with the UpdateBook method # consuming at twice rate as the DeleteBook method. metric_rules:
- selector: "*" metric_costs: library.googleapis.com/read_calls: 1
- selector: google.example.library.v1.LibraryService.UpdateBook metric_costs: library.googleapis.com/write_calls: 2
- selector: google.example.library.v1.LibraryService.DeleteBook metric_costs: library.googleapis.com/write_calls: 1 Corresponding Metric definition: metrics:
- name: library.googleapis.com/read_calls display_name: Read requests metric_kind: DELTA value_type: INT64
- name: library.googleapis.com/write_calls display_name: Write requests metric_kind: DELTA value_type: INT64
Protobuf type google.api.Quota
QuotaLimit
QuotaLimit defines a specific limit that applies over a specified duration
for a limit type. There can be at most one limit for a duration and limit
type combination defined within a QuotaGroup.
Protobuf type google.api.QuotaLimit
QuotaLimit.Builder
QuotaLimit defines a specific limit that applies over a specified duration
for a limit type. There can be at most one limit for a duration and limit
type combination defined within a QuotaGroup.
Protobuf type google.api.QuotaLimit
QuotaProto
ResourceDescriptor
A simple descriptor of a resource type. ResourceDescriptor annotates a resource message (either by means of a protobuf annotation or use in the service config), and associates the resource's schema, the resource type, and the pattern of the resource name. Example: message Topic { // Indicates this message defines a resource schema. // Declares the resource type in the format of {service}/{kind}. // For Kubernetes resources, the format is {api group}/{kind}. option (google.api.resource) = { type: "pubsub.googleapis.com/Topic" pattern: "projects/{project}/topics/{topic}" }; } The ResourceDescriptor Yaml config will look like: resources:
- type: "pubsub.googleapis.com/Topic" pattern: "projects/{project}/topics/{topic}" Sometimes, resources have multiple patterns, typically because they can live under multiple parents. Example: message LogEntry { option (google.api.resource) = { type: "logging.googleapis.com/LogEntry" pattern: "projects/{project}/logs/{log}" pattern: "folders/{folder}/logs/{log}" pattern: "organizations/{organization}/logs/{log}" pattern: "billingAccounts/{billing_account}/logs/{log}" }; } The ResourceDescriptor Yaml config will look like: resources:
- type: 'logging.googleapis.com/LogEntry' pattern: "projects/{project}/logs/{log}" pattern: "folders/{folder}/logs/{log}" pattern: "organizations/{organization}/logs/{log}" pattern: "billingAccounts/{billing_account}/logs/{log}"
Protobuf type google.api.ResourceDescriptor
ResourceDescriptor.Builder
A simple descriptor of a resource type. ResourceDescriptor annotates a resource message (either by means of a protobuf annotation or use in the service config), and associates the resource's schema, the resource type, and the pattern of the resource name. Example: message Topic { // Indicates this message defines a resource schema. // Declares the resource type in the format of {service}/{kind}. // For Kubernetes resources, the format is {api group}/{kind}. option (google.api.resource) = { type: "pubsub.googleapis.com/Topic" pattern: "projects/{project}/topics/{topic}" }; } The ResourceDescriptor Yaml config will look like: resources:
- type: "pubsub.googleapis.com/Topic" pattern: "projects/{project}/topics/{topic}" Sometimes, resources have multiple patterns, typically because they can live under multiple parents. Example: message LogEntry { option (google.api.resource) = { type: "logging.googleapis.com/LogEntry" pattern: "projects/{project}/logs/{log}" pattern: "folders/{folder}/logs/{log}" pattern: "organizations/{organization}/logs/{log}" pattern: "billingAccounts/{billing_account}/logs/{log}" }; } The ResourceDescriptor Yaml config will look like: resources:
- type: 'logging.googleapis.com/LogEntry' pattern: "projects/{project}/logs/{log}" pattern: "folders/{folder}/logs/{log}" pattern: "organizations/{organization}/logs/{log}" pattern: "billingAccounts/{billing_account}/logs/{log}"
Protobuf type google.api.ResourceDescriptor
ResourceProto
ResourceReference
Defines a proto annotation that describes a string field that refers to an API resource.
Protobuf type google.api.ResourceReference
ResourceReference.Builder
Defines a proto annotation that describes a string field that refers to an API resource.
Protobuf type google.api.ResourceReference
RoutingParameter
A projection from an input message to the GRPC or REST header.
Protobuf type google.api.RoutingParameter
RoutingParameter.Builder
A projection from an input message to the GRPC or REST header.
Protobuf type google.api.RoutingParameter
RoutingProto
RoutingRule
Specifies the routing information that should be sent along with the request
in the form of routing header.
NOTE: All service configuration rules follow the "last one wins" order.
The examples below will apply to an RPC which has the following request type:
Message Definition:
message Request {
// The name of the Table
// Values can be of the following formats:
// - projects/<project>/tables/<table>
// - projects/<project>/instances/<instance>/tables/<table>
// - region/<region>/zones/<zone>/tables/<table>
string table_name = 1;
// This value specifies routing for replication.
// It can be in the following formats:
// - profiles/<profile_id>
// - a legacy profile_id that can be any string
string app_profile_id = 2;
}
Example message:
{
table_name: projects/proj_foo/instances/instance_bar/table/table_baz,
app_profile_id: profiles/prof_qux
}
The routing header consists of one or multiple key-value pairs. Every key
and value must be percent-encoded, and joined together in the format of
key1=value1&key2=value2.
In the examples below I am skipping the percent-encoding for readablity.
Example 1
Extracting a field from the request to put into the routing header
unchanged, with the key equal to the field name.
annotation:
option (google.api.routing) = {
// Take the app_profile_id.
routing_parameters {
field: "app_profile_id"
}
};
result:
x-goog-request-params: app_profile_id=profiles/prof_qux
Example 2
Extracting a field from the request to put into the routing header
unchanged, with the key different from the field name.
annotation:
option (google.api.routing) = {
// Take the app_profile_id, but name it routing_id in the header.
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params: routing_id=profiles/prof_qux
Example 3
Extracting a field from the request to put into the routing
header, while matching a path template syntax on the field's value.
NB: it is more useful to send nothing than to send garbage for the purpose
of dynamic routing, since garbage pollutes cache. Thus the matching.
Sub-example 3a
The field matches the template.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed (with project-based
// syntax).
routing_parameters {
field: "table_name"
path_template: "{table_name=projects/*/instances/*/*}"
}
};
result:
x-goog-request-params:
table_name=projects/proj_foo/instances/instance_bar/table/table_baz
Sub-example 3b
The field does not match the template.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed (with region-based
// syntax).
routing_parameters {
field: "table_name"
path_template: "{table_name=regions/*/zones/*/*}"
}
};
result:
<no routing header will be sent>
Sub-example 3c
Multiple alternative conflictingly named path templates are
specified. The one that matches is used to construct the header.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed, whether
// using the region- or projects-based syntax.
routing_parameters {
field: "table_name"
path_template: "{table_name=regions/*/zones/*/*}"
}
routing_parameters {
field: "table_name"
path_template: "{table_name=projects/*/instances/*/*}"
}
};
result:
x-goog-request-params:
table_name=projects/proj_foo/instances/instance_bar/table/table_baz
Example 4
Extracting a single routing header key-value pair by matching a
template syntax on (a part of) a single request field.
annotation:
option (google.api.routing) = {
// Take just the project id from the table_name field.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
};
result:
x-goog-request-params: routing_id=projects/proj_foo
Example 5
Extracting a single routing header key-value pair by matching
several conflictingly named path templates on (parts of) a single request
field. The last template to match "wins" the conflict.
annotation:
option (google.api.routing) = {
// If the table_name does not have instances information,
// take just the project id for routing.
// Otherwise take project + instance.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*/instances/*}/*"
}
};
result:
x-goog-request-params:
routing_id=projects/proj_foo/instances/instance_bar
Example 6
Extracting multiple routing header key-value pairs by matching
several non-conflicting path templates on (parts of) a single request field.
Sub-example 6a
Make the templates strict, so that if the table_name does not
have an instance information, nothing is sent.
annotation:
option (google.api.routing) = {
// The routing code needs two keys instead of one composite
// but works only for the tables with the "project-instance" name
// syntax.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/instances/*/*"
}
routing_parameters {
field: "table_name"
path_template: "projects/*/{instance_id=instances/*}/*"
}
};
result:
x-goog-request-params:
project_id=projects/proj_foo&instance_id=instances/instance_bar
Sub-example 6b
Make the templates loose, so that if the table_name does not
have an instance information, just the project id part is sent.
annotation:
option (google.api.routing) = {
// The routing code wants two keys instead of one composite
// but will work with just the project_id for tables without
// an instance in the table_name.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "projects/*/{instance_id=instances/*}/*"
}
};
result (is the same as 6a for our example message because it has the instance
information):
x-goog-request-params:
project_id=projects/proj_foo&instance_id=instances/instance_bar
Example 7
Extracting multiple routing header key-value pairs by matching
several path templates on multiple request fields.
NB: note that here there is no way to specify sending nothing if one of the
fields does not match its template. E.g. if the table_name is in the wrong
format, the project_id will not be sent, but the routing_id will be.
The backend routing code has to be aware of that and be prepared to not
receive a full complement of keys if it expects multiple.
annotation:
option (google.api.routing) = {
// The routing needs both project_id and routing_id
// (from the app_profile_id field) for routing.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/*"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params:
project_id=projects/proj_foo&routing_id=profiles/prof_qux
Example 8
Extracting a single routing header key-value pair by matching
several conflictingly named path templates on several request fields. The
last template to match "wins" the conflict.
annotation:
option (google.api.routing) = {
// The routing_id can be a project id or a region id depending on
// the table name format, but only if the app_profile_id is not set.
// If app_profile_id is set it should be used instead.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=regions/*}/*"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params: routing_id=profiles/prof_qux
Example 9
Bringing it all together.
annotation:
option (google.api.routing) = {
// For routing both table_location and a routing_id are needed.
//
// table_location can be either an instance id or a region+zone id.
//
// For routing_id, take the value of app_profile_id
// - If it's in the format profiles/<profile_id>, send
// just the <profile_id> part.
// - If it's any other literal, send it as is.
// If the app_profile_id is empty, and the table_name starts with
// the project_id, send that instead.
routing_parameters {
field: "table_name"
path_template: "projects/*/{table_location=instances/*}/tables/*"
}
routing_parameters {
field: "table_name"
path_template: "{table_location=regions/*/zones/*}/tables/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/**"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
routing_parameters {
field: "app_profile_id"
path_template: "profiles/{routing_id=*}"
}
};
result:
x-goog-request-params:
table_location=instances/instance_bar&routing_id=prof_qux
Protobuf type google.api.RoutingRule
RoutingRule.Builder
Specifies the routing information that should be sent along with the request
in the form of routing header.
NOTE: All service configuration rules follow the "last one wins" order.
The examples below will apply to an RPC which has the following request type:
Message Definition:
message Request {
// The name of the Table
// Values can be of the following formats:
// - projects/<project>/tables/<table>
// - projects/<project>/instances/<instance>/tables/<table>
// - region/<region>/zones/<zone>/tables/<table>
string table_name = 1;
// This value specifies routing for replication.
// It can be in the following formats:
// - profiles/<profile_id>
// - a legacy profile_id that can be any string
string app_profile_id = 2;
}
Example message:
{
table_name: projects/proj_foo/instances/instance_bar/table/table_baz,
app_profile_id: profiles/prof_qux
}
The routing header consists of one or multiple key-value pairs. Every key
and value must be percent-encoded, and joined together in the format of
key1=value1&key2=value2.
In the examples below I am skipping the percent-encoding for readablity.
Example 1
Extracting a field from the request to put into the routing header
unchanged, with the key equal to the field name.
annotation:
option (google.api.routing) = {
// Take the app_profile_id.
routing_parameters {
field: "app_profile_id"
}
};
result:
x-goog-request-params: app_profile_id=profiles/prof_qux
Example 2
Extracting a field from the request to put into the routing header
unchanged, with the key different from the field name.
annotation:
option (google.api.routing) = {
// Take the app_profile_id, but name it routing_id in the header.
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params: routing_id=profiles/prof_qux
Example 3
Extracting a field from the request to put into the routing
header, while matching a path template syntax on the field's value.
NB: it is more useful to send nothing than to send garbage for the purpose
of dynamic routing, since garbage pollutes cache. Thus the matching.
Sub-example 3a
The field matches the template.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed (with project-based
// syntax).
routing_parameters {
field: "table_name"
path_template: "{table_name=projects/*/instances/*/*}"
}
};
result:
x-goog-request-params:
table_name=projects/proj_foo/instances/instance_bar/table/table_baz
Sub-example 3b
The field does not match the template.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed (with region-based
// syntax).
routing_parameters {
field: "table_name"
path_template: "{table_name=regions/*/zones/*/*}"
}
};
result:
<no routing header will be sent>
Sub-example 3c
Multiple alternative conflictingly named path templates are
specified. The one that matches is used to construct the header.
annotation:
option (google.api.routing) = {
// Take the table_name, if it's well-formed, whether
// using the region- or projects-based syntax.
routing_parameters {
field: "table_name"
path_template: "{table_name=regions/*/zones/*/*}"
}
routing_parameters {
field: "table_name"
path_template: "{table_name=projects/*/instances/*/*}"
}
};
result:
x-goog-request-params:
table_name=projects/proj_foo/instances/instance_bar/table/table_baz
Example 4
Extracting a single routing header key-value pair by matching a
template syntax on (a part of) a single request field.
annotation:
option (google.api.routing) = {
// Take just the project id from the table_name field.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
};
result:
x-goog-request-params: routing_id=projects/proj_foo
Example 5
Extracting a single routing header key-value pair by matching
several conflictingly named path templates on (parts of) a single request
field. The last template to match "wins" the conflict.
annotation:
option (google.api.routing) = {
// If the table_name does not have instances information,
// take just the project id for routing.
// Otherwise take project + instance.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*/instances/*}/*"
}
};
result:
x-goog-request-params:
routing_id=projects/proj_foo/instances/instance_bar
Example 6
Extracting multiple routing header key-value pairs by matching
several non-conflicting path templates on (parts of) a single request field.
Sub-example 6a
Make the templates strict, so that if the table_name does not
have an instance information, nothing is sent.
annotation:
option (google.api.routing) = {
// The routing code needs two keys instead of one composite
// but works only for the tables with the "project-instance" name
// syntax.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/instances/*/*"
}
routing_parameters {
field: "table_name"
path_template: "projects/*/{instance_id=instances/*}/*"
}
};
result:
x-goog-request-params:
project_id=projects/proj_foo&instance_id=instances/instance_bar
Sub-example 6b
Make the templates loose, so that if the table_name does not
have an instance information, just the project id part is sent.
annotation:
option (google.api.routing) = {
// The routing code wants two keys instead of one composite
// but will work with just the project_id for tables without
// an instance in the table_name.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "projects/*/{instance_id=instances/*}/*"
}
};
result (is the same as 6a for our example message because it has the instance
information):
x-goog-request-params:
project_id=projects/proj_foo&instance_id=instances/instance_bar
Example 7
Extracting multiple routing header key-value pairs by matching
several path templates on multiple request fields.
NB: note that here there is no way to specify sending nothing if one of the
fields does not match its template. E.g. if the table_name is in the wrong
format, the project_id will not be sent, but the routing_id will be.
The backend routing code has to be aware of that and be prepared to not
receive a full complement of keys if it expects multiple.
annotation:
option (google.api.routing) = {
// The routing needs both project_id and routing_id
// (from the app_profile_id field) for routing.
routing_parameters {
field: "table_name"
path_template: "{project_id=projects/*}/*"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params:
project_id=projects/proj_foo&routing_id=profiles/prof_qux
Example 8
Extracting a single routing header key-value pair by matching
several conflictingly named path templates on several request fields. The
last template to match "wins" the conflict.
annotation:
option (google.api.routing) = {
// The routing_id can be a project id or a region id depending on
// the table name format, but only if the app_profile_id is not set.
// If app_profile_id is set it should be used instead.
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=regions/*}/*"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
};
result:
x-goog-request-params: routing_id=profiles/prof_qux
Example 9
Bringing it all together.
annotation:
option (google.api.routing) = {
// For routing both table_location and a routing_id are needed.
//
// table_location can be either an instance id or a region+zone id.
//
// For routing_id, take the value of app_profile_id
// - If it's in the format profiles/<profile_id>, send
// just the <profile_id> part.
// - If it's any other literal, send it as is.
// If the app_profile_id is empty, and the table_name starts with
// the project_id, send that instead.
routing_parameters {
field: "table_name"
path_template: "projects/*/{table_location=instances/*}/tables/*"
}
routing_parameters {
field: "table_name"
path_template: "{table_location=regions/*/zones/*}/tables/*"
}
routing_parameters {
field: "table_name"
path_template: "{routing_id=projects/*}/**"
}
routing_parameters {
field: "app_profile_id"
path_template: "{routing_id=}"
}
routing_parameters {
field: "app_profile_id"
path_template: "profiles/{routing_id=*}"
}
};
result:
x-goog-request-params:
table_location=instances/instance_bar&routing_id=prof_qux
Protobuf type google.api.RoutingRule
Service
Service is the root object of Google service configuration schema. It
describes basic information about a service, such as the name and the
title, and delegates other aspects to sub-sections. Each sub-section is
either a proto message or a repeated proto message that configures a
specific aspect, such as auth. See each proto message definition for details.
Example:
type: google.api.Service
name: calendar.googleapis.com
title: Google Calendar API
apis:
- name: google.calendar.v3.Calendar
authentication:
providers:
- id: google_calendar_auth jwks_uri: https://www.googleapis.com/oauth2/v1/certs issuer: https://securetoken.google.com rules:
- selector: "*" requirements: provider_id: google_calendar_auth
Protobuf type google.api.Service
Service.Builder
Service is the root object of Google service configuration schema. It
describes basic information about a service, such as the name and the
title, and delegates other aspects to sub-sections. Each sub-section is
either a proto message or a repeated proto message that configures a
specific aspect, such as auth. See each proto message definition for details.
Example:
type: google.api.Service
name: calendar.googleapis.com
title: Google Calendar API
apis:
- name: google.calendar.v3.Calendar
authentication:
providers:
- id: google_calendar_auth jwks_uri: https://www.googleapis.com/oauth2/v1/certs issuer: https://securetoken.google.com rules:
- selector: "*" requirements: provider_id: google_calendar_auth
Protobuf type google.api.Service
ServiceProto
SourceInfo
Source information used to create a Service Config
Protobuf type google.api.SourceInfo
SourceInfo.Builder
Source information used to create a Service Config
Protobuf type google.api.SourceInfo
SourceInfoProto
SystemParameter
Define a parameter's name and location. The parameter may be passed as either an HTTP header or a URL query parameter, and if both are passed the behavior is implementation-dependent.
Protobuf type google.api.SystemParameter
SystemParameter.Builder
Define a parameter's name and location. The parameter may be passed as either an HTTP header or a URL query parameter, and if both are passed the behavior is implementation-dependent.
Protobuf type google.api.SystemParameter
SystemParameterProto
SystemParameterRule
Define a system parameter rule mapping system parameter definitions to methods.
Protobuf type google.api.SystemParameterRule
SystemParameterRule.Builder
Define a system parameter rule mapping system parameter definitions to methods.
Protobuf type google.api.SystemParameterRule
SystemParameters
System parameter configuration
A system parameter is a special kind of parameter defined by the API system, not by an individual API. It is typically mapped to an HTTP header and/or a URL query parameter. This configuration specifies which methods change the names of the system parameters.
Protobuf type google.api.SystemParameters
SystemParameters.Builder
System parameter configuration
A system parameter is a special kind of parameter defined by the API system, not by an individual API. It is typically mapped to an HTTP header and/or a URL query parameter. This configuration specifies which methods change the names of the system parameters.
Protobuf type google.api.SystemParameters
Usage
Configuration controlling usage of a service.
Protobuf type google.api.Usage
Usage.Builder
Configuration controlling usage of a service.
Protobuf type google.api.Usage
UsageProto
UsageRule
Usage configuration rules for the service. NOTE: Under development. Use this rule to configure unregistered calls for the service. Unregistered calls are calls that do not contain consumer project identity. (Example: calls that do not contain an API key). By default, API methods do not allow unregistered calls, and each method call must be identified by a consumer project identity. Use this rule to allow/disallow unregistered calls. Example of an API that wants to allow unregistered calls for entire service. usage: rules:
- selector: "*" allow_unregistered_calls: true Example of a method that wants to allow unregistered calls. usage: rules:
- selector: "google.example.library.v1.LibraryService.CreateBook" allow_unregistered_calls: true
Protobuf type google.api.UsageRule
UsageRule.Builder
Usage configuration rules for the service. NOTE: Under development. Use this rule to configure unregistered calls for the service. Unregistered calls are calls that do not contain consumer project identity. (Example: calls that do not contain an API key). By default, API methods do not allow unregistered calls, and each method call must be identified by a consumer project identity. Use this rule to allow/disallow unregistered calls. Example of an API that wants to allow unregistered calls for entire service. usage: rules:
- selector: "*" allow_unregistered_calls: true Example of a method that wants to allow unregistered calls. usage: rules:
- selector: "google.example.library.v1.LibraryService.CreateBook" allow_unregistered_calls: true
Protobuf type google.api.UsageRule
Visibility
Visibility defines restrictions for the visibility of service
elements. Restrictions are specified using visibility labels
(e.g., PREVIEW) that are elsewhere linked to users and projects.
Users and projects can have access to more than one visibility label. The
effective visibility for multiple labels is the union of each label's
elements, plus any unrestricted elements.
If an element and its parents have no restrictions, visibility is
unconditionally granted.
Example:
visibility:
rules:
- selector: google.calendar.Calendar.EnhancedSearch restriction: PREVIEW
- selector: google.calendar.Calendar.Delegate restriction: INTERNAL Here, all methods are publicly visible except for the restricted methods EnhancedSearch and Delegate.
Protobuf type google.api.Visibility
Visibility.Builder
Visibility defines restrictions for the visibility of service
elements. Restrictions are specified using visibility labels
(e.g., PREVIEW) that are elsewhere linked to users and projects.
Users and projects can have access to more than one visibility label. The
effective visibility for multiple labels is the union of each label's
elements, plus any unrestricted elements.
If an element and its parents have no restrictions, visibility is
unconditionally granted.
Example:
visibility:
rules:
- selector: google.calendar.Calendar.EnhancedSearch restriction: PREVIEW
- selector: google.calendar.Calendar.Delegate restriction: INTERNAL Here, all methods are publicly visible except for the restricted methods EnhancedSearch and Delegate.
Protobuf type google.api.Visibility
VisibilityProto
VisibilityRule
A visibility rule provides visibility configuration for an individual API element.
Protobuf type google.api.VisibilityRule
VisibilityRule.Builder
A visibility rule provides visibility configuration for an individual API element.
Protobuf type google.api.VisibilityRule
Interfaces
AdviceOrBuilder
AuthProviderOrBuilder
AuthRequirementOrBuilder
AuthenticationOrBuilder
AuthenticationRuleOrBuilder
BackendOrBuilder
BackendRuleOrBuilder
Billing.BillingDestinationOrBuilder
BillingOrBuilder
ConfigChangeOrBuilder
ContextOrBuilder
ContextRuleOrBuilder
ControlOrBuilder
CustomHttpPatternOrBuilder
Distribution.BucketOptions.ExplicitOrBuilder
Distribution.BucketOptions.ExponentialOrBuilder
Distribution.BucketOptions.LinearOrBuilder
Distribution.BucketOptionsOrBuilder
Distribution.ExemplarOrBuilder
Distribution.RangeOrBuilder
DistributionOrBuilder
DocumentationOrBuilder
DocumentationRuleOrBuilder
EndpointOrBuilder
HttpBodyOrBuilder
HttpOrBuilder
HttpRuleOrBuilder
JwtLocationOrBuilder
LabelDescriptorOrBuilder
LogDescriptorOrBuilder
Logging.LoggingDestinationOrBuilder
LoggingOrBuilder
MetricDescriptor.MetricDescriptorMetadataOrBuilder
MetricDescriptorOrBuilder
MetricOrBuilder
MetricRuleOrBuilder
MonitoredResourceDescriptorOrBuilder
MonitoredResourceMetadataOrBuilder
MonitoredResourceOrBuilder
Monitoring.MonitoringDestinationOrBuilder
MonitoringOrBuilder
OAuthRequirementsOrBuilder
PageOrBuilder
ProjectPropertiesOrBuilder
PropertyOrBuilder
QuotaLimitOrBuilder
QuotaOrBuilder
ResourceDescriptorOrBuilder
ResourceReferenceOrBuilder
RoutingParameterOrBuilder
RoutingRuleOrBuilder
ServiceOrBuilder
SourceInfoOrBuilder
SystemParameterOrBuilder
SystemParameterRuleOrBuilder
SystemParametersOrBuilder
UsageOrBuilder
UsageRuleOrBuilder
VisibilityOrBuilder
VisibilityRuleOrBuilder
Enums
BackendRule.AuthenticationCase
BackendRule.PathTranslation
Path Translation specifies how to combine the backend address with the
request path in order to produce the appropriate forwarding URL for the
request.
Path Translation is applicable only to HTTP-based backends. Backends which
do not accept requests over HTTP/HTTPS should leave path_translation
unspecified.
Protobuf enum google.api.BackendRule.PathTranslation
ChangeType
Classifies set of possible modifications to an object in the service configuration.
Protobuf enum google.api.ChangeType
Distribution.BucketOptions.OptionsCase
ErrorReason
Defines the supported values for google.rpc.ErrorInfo.reason for the
googleapis.com error domain. This error domain is reserved for Service
Infrastructure.
For each error info of this domain, the metadata key "service" refers to the
logical identifier of an API service, such as "pubsub.googleapis.com". The
"consumer" refers to the entity that consumes an API Service. It typically is
a Google project that owns the client application or the server resource,
such as "projects/123". Other metadata keys are specific to each error
reason. For more information, see the definition of the specific error
reason.
Protobuf enum google.api.ErrorReason
FieldBehavior
An indicator of the behavior of a given field (for example, that a field is required in requests, or given as output but ignored as input). This does not change the behavior in protocol buffers itself; it only denotes the behavior and may affect how API tooling handles the field. Note: This enum may receive new values in the future.
Protobuf enum google.api.FieldBehavior
HttpRule.PatternCase
JwtLocation.InCase
LabelDescriptor.ValueType
Value types that can be used as label values.
Protobuf enum google.api.LabelDescriptor.ValueType
LaunchStage
The launch stage as defined by Google Cloud Platform Launch Stages.
Protobuf enum google.api.LaunchStage
MetricDescriptor.MetricKind
The kind of measurement. It describes how the data is reported. For information on setting the start time and end time based on the MetricKind, see TimeInterval.
Protobuf enum google.api.MetricDescriptor.MetricKind
MetricDescriptor.ValueType
The value type of a metric.
Protobuf enum google.api.MetricDescriptor.ValueType
Property.PropertyType
Supported data type of the property values
Protobuf enum google.api.Property.PropertyType
ResourceDescriptor.History
A description of the historical or future-looking state of the resource pattern.
Protobuf enum google.api.ResourceDescriptor.History
ResourceDescriptor.Style
A flag representing a specific style that a resource claims to conform to.
Protobuf enum google.api.ResourceDescriptor.Style