package google.api

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message Advice

config_change.proto:62

Generated advice about this change, used for providing more information about how a change will affect the existing service.

Used in: ConfigChange

message AuthProvider

auth.proto:79

Configuration for an anthentication provider, including support for [JSON Web Token (JWT)](https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32).

Used in: Authentication

message AuthRequirement

auth.proto:156

User-defined authentication requirements, including support for [JSON Web Token (JWT)](https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32).

Used in: AuthenticationRule

message Authentication

auth.proto:42

`Authentication` defines the authentication configuration for an API. Example for an API targeted for external use: 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

Used in: Service

message AuthenticationRule

auth.proto:61

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.

Used in: Authentication

message Backend

backend.proto:27

`Backend` defines the backend configuration for a service.

Used in: Service

message BackendRule

backend.proto:35

A backend rule provides configuration for an individual API element.

Used in: Backend

message Billing

billing.proto:49

Billing related configuration of the service. The following example shows how to configure monitored resources and metrics for billing: 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. metrics: - name: library.googleapis.com/book/borrowed_count metric_kind: DELTA value_type: INT64 billing: consumer_destinations: - monitored_resource: library.googleapis.com/branch metrics: - library.googleapis.com/book/borrowed_count

Used in: Service

message Billing.BillingDestination

billing.proto:52

Configuration of a specific billing destination (Currently only support bill against consumer project).

Used in: Billing

enum ChangeType

config_change.proto:70

Classifies set of possible modifications to an object in the service configuration.

Used in: ConfigChange

message ConfigChange

config_change.proto:32

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.

message Context

context.proto:43

`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.ProjectContext` and `google.rpc.context.OriginContext`. Available context types are defined in package `google.rpc.context`.

Used in: Service

message ContextRule

context.proto:52

A context rule provides information about the context for an individual API element.

Used in: Context

message Control

control.proto:29

Selects and configures the service controller used by the service. The service controller handles features like abuse, quota, billing, logging, monitoring, etc.

Used in: Service

message CustomHttpPattern

http.proto:312

A custom pattern is used for defining custom HTTP verb.

Used in: HttpRule

message Distribution

distribution.proto:44

`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.

message Distribution.BucketOptions

distribution.proto:69

`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.

Used in: Distribution

message Distribution.BucketOptions.Explicit

distribution.proto:121

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.

Used in: BucketOptions

message Distribution.BucketOptions.Exponential

distribution.proto:99

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)).

Used in: BucketOptions

message Distribution.BucketOptions.Linear

distribution.proto:79

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)).

Used in: BucketOptions

message Distribution.Exemplar

distribution.proto:144

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.

Used in: Distribution

message Distribution.Range

distribution.proto:46

The range of the population values.

Used in: Distribution

message Documentation

documentation.proto:81

`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: &#40;== include google/foo/overview.md ==&#41; - name: Tutorial content: &#40;== include google/foo/tutorial.md ==&#41; subpages; - name: Java content: &#40;== include google/foo/tutorial_java.md ==&#41; rules: - 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>&#91;fully.qualified.proto.name]&#91;]</code></pre> To override the display text used for the link, this can be used: <pre><code>&#91;display text]&#91;fully.qualified.proto.name]</code></pre> Text can be excluded from doc using the following notation: <pre><code>&#40;-- internal comment --&#41;</code></pre> A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The `include` directive includes a markdown file from an external source: <pre><code>&#40;== include path/to/file ==&#41;</code></pre> The `resource_for` directive 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>&#40;== resource_for v1.shelves.books ==&#41;</code></pre> The directive `suppress_warning` does not directly affect documentation and is documented together with service config validation.

Used in: Service

message DocumentationRule

documentation.proto:114

A documentation rule provides information about individual API elements.

Used in: Documentation

message Endpoint

endpoint.proto:44

`Endpoint` describes a network endpoint that serves a set of APIs. A service may expose any number of endpoints, and all endpoints share the same service configuration, such as quota configuration and monitoring configuration. 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

Used in: Service

enum FieldBehavior

field_behavior.proto:49

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.

message Http

http.proto:30

Defines the HTTP configuration for an API service. It contains a list of [HttpRule][google.api.HttpRule], each specifying the mapping of an RPC method to one or more HTTP REST API methods.

Used in: Service

message HttpBody

httpbody.proto:66

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.

message HttpRule

http.proto:262

`HttpRule` defines the mapping of an RPC method to one or more HTTP REST API methods. The mapping specifies how different portions of the RPC request message are mapped to URL path, URL query parameters, and HTTP request body. The mapping is typically specified as an `google.api.http` annotation on the RPC method, see "google/api/annotations.proto" for details. The mapping consists of a field specifying the path template and method kind. The path template can refer to fields in the request message, as in the example below which describes a REST GET operation on a resource collection of messages: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http).get = "/v1/messages/{message_id}/{sub.subfield}"; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // mapped to the URL SubMessage sub = 2; // `sub.subfield` is url-mapped } message Message { string text = 1; // content of the resource } The same http annotation can alternatively be expressed inside the `GRPC API Configuration` YAML file. http: rules: - selector: <proto_package_name>.Messaging.GetMessage get: /v1/messages/{message_id}/{sub.subfield} This definition enables an automatic, bidrectional mapping of HTTP JSON to RPC. Example: HTTP | RPC -----|----- `GET /v1/messages/123456/foo` | `GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))` In general, not only fields but also field paths can be referenced from a path pattern. Fields mapped to the path pattern cannot be repeated and must have a primitive (non-message) type. Any fields in the request message which are not bound by the path pattern automatically become (optional) HTTP query parameters. Assume the following definition of the request message: 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 the URL int64 revision = 2; // becomes a parameter SubMessage sub = 3; // `sub.subfield` becomes a parameter } This enables a HTTP JSON to RPC mapping as below: HTTP | RPC -----|----- `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 HTTP parameters must have a primitive type or a repeated primitive type. Message types are not allowed. In the case of a repeated type, the parameter can be repeated in the URL, as in `...?param=A&param=B`. For HTTP method kinds which 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) = { put: "/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 | RPC -----|----- `PUT /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) = { put: "/v1/messages/{message_id}" body: "*" }; } } message Message { string message_id = 1; string text = 2; } The following HTTP JSON to RPC mapping is enabled: HTTP | RPC -----|----- `PUT /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 of 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 | RPC -----|----- `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 The rules for mapping HTTP path, query parameters, and body fields to the request message are as follows: 1. The `body` field specifies either `*` or a field path, or is omitted. If omitted, it indicates there is no HTTP request body. 2. Leaf fields (recursive expansion of nested messages in the request) can be classified into three types: (a) Matched in the URL template. (b) Covered by body (if body is `*`, everything except (a) fields; else everything under the body field) (c) All other fields. 3. URL query parameters found in the HTTP request are mapped to (c) fields. 4. Any body sent with an HTTP request can contain only (b) fields. The syntax of the path template is as follows: Template = "/" Segments [ Verb ] ; Segments = Segment { "/" Segment } ; Segment = "*" | "**" | LITERAL | Variable ; Variable = "{" FieldPath [ "=" Segments ] "}" ; FieldPath = IDENT { "." IDENT } ; Verb = ":" LITERAL ; The syntax `*` matches a single path segment. The syntax `**` matches zero or more path segments, which must be the last part of the path except the `Verb`. The syntax `LITERAL` matches literal text in the path. The syntax `Variable` matches 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=*}`. If a variable contains exactly one path segment, such as `"{var}"` or `"{var=*}"`, when such a variable is expanded into a URL path, all characters except `[-_.~0-9a-zA-Z]` are percent-encoded. Such variables show up in the Discovery Document as `{var}`. If a variable contains one or more path segments, such as `"{var=foo/*}"` or `"{var=**}"`, when such a variable is expanded into a URL path, all characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. Such variables show up in the Discovery Document as `{+var}`. NOTE: While the single segment variable matches the semantics of [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String Expansion, the multi segment variable **does not** match RFC 6570 Reserved Expansion. The reason is that the Reserved Expansion does not expand special characters like `?` and `#`, which would lead to invalid URLs. NOTE: the field paths in variables and in the `body` must not refer to repeated fields or map fields.

Used in: Http

message LabelDescriptor

label.proto:28

A description of a label.

Used in: LogDescriptor, MetricDescriptor, MonitoredResourceDescriptor

enum LabelDescriptor.ValueType

label.proto:30

Value types that can be used as label values.

Used in: LabelDescriptor

enum LaunchStage

launch_stage.proto:28

The launch stage as defined by [Google Cloud Platform Launch Stages](http://cloud.google.com/terms/launch-stages).

message LogDescriptor

log.proto:36

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

Used in: Service

message Logging

logging.proto:57

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

Used in: Service

message Logging.LoggingDestination

logging.proto:60

Configuration of a specific logging destination (the producer project or the consumer project).

Used in: Logging

message Metric

metric.proto:184

A specific metric, identified by specifying values for all of the labels of a [`MetricDescriptor`][google.api.MetricDescriptor].

message MetricDescriptor

metric.proto:31

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.

Used in: Service

enum MetricDescriptor.MetricKind

metric.proto:33

The kind of measurement. It describes how the data is reported.

Used in: MetricDescriptor

enum MetricDescriptor.ValueType

metric.proto:52

The value type of a metric.

Used in: MetricDescriptor

message MetricRule

quota.proto:95

Bind API methods to metrics. Binding a method to a metric causes that metric's configured quota, billing, and monitoring behaviors to apply to the method call. Used by metric-based quotas only.

Used in: Quota

message MonitoredResource

monitored_resource.proto:82

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][google.api.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][google.api.MonitoredResourceDescriptor] for `"gce_instance"` has labels `"instance_id"` and `"zone"`: { "type": "gce_instance", "labels": { "instance_id": "12345678901234", "zone": "us-central1-a" }}

message MonitoredResourceDescriptor

monitored_resource.proto:39

An object that describes the schema of a [MonitoredResource][google.api.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.

Used in: Service

message MonitoredResourceMetadata

monitored_resource.proto:100

Auxiliary metadata for a [MonitoredResource][google.api.MonitoredResource] object. [MonitoredResource][google.api.MonitoredResource] objects contain the minimum set of information to uniquely identify a monitored resource instance. There is some other useful auxiliary metadata. Google Stackdriver Monitoring & Logging uses an ingestion pipeline to extract metadata for cloud resources of all types , and stores the metadata in this message.

message Monitoring

monitoring.proto:65

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/overdue_count` metric is only sent to the consumer 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. metrics: - name: library.googleapis.com/book/returned_count metric_kind: DELTA value_type: INT64 labels: - key: /customer_id - name: library.googleapis.com/book/overdue_count metric_kind: GAUGE value_type: INT64 labels: - key: /customer_id 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/overdue_count

Used in: Service

message Monitoring.MonitoringDestination

monitoring.proto:68

Configuration of a specific monitoring destination (the producer project or the consumer project).

Used in: Monitoring

message OAuthRequirements

auth.proto:143

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.

Used in: AuthenticationRule

message Page

documentation.proto:133

Represents a documentation page. A page can contain subpages to represent nested documentation set structure.

Used in: Documentation

message ProjectProperties

consumer.proto:41

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

message Property

consumer.proto:56

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.

Used in: ProjectProperties

enum Property.PropertyType

consumer.proto:58

Supported data type of the property values

Used in: Property

message Quota

quota.proto:77

Quota configuration helps to achieve fairness and budgeting in service usage. The 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

Used in: Service

message QuotaLimit

quota.proto:113

`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`.

Used in: Quota

message ResourceDescriptor

resource.proto:154

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" name_descriptor: { pattern: "projects/{project}/topics/{topic}" parent_type: "cloudresourcemanager.googleapis.com/Project" parent_name_extractor: "projects/{project}" } }; } The ResourceDescriptor Yaml config will look like: resources: - type: "pubsub.googleapis.com/Topic" name_descriptor: - pattern: "projects/{project}/topics/{topic}" parent_type: "cloudresourcemanager.googleapis.com/Project" parent_name_extractor: "projects/{project}" 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" name_descriptor: { pattern: "projects/{project}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Project" parent_name_extractor: "projects/{project}" } name_descriptor: { pattern: "folders/{folder}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Folder" parent_name_extractor: "folders/{folder}" } name_descriptor: { pattern: "organizations/{organization}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Organization" parent_name_extractor: "organizations/{organization}" } name_descriptor: { pattern: "billingAccounts/{billing_account}/logs/{log}" parent_type: "billing.googleapis.com/BillingAccount" parent_name_extractor: "billingAccounts/{billing_account}" } }; } The ResourceDescriptor Yaml config will look like: resources: - type: 'logging.googleapis.com/LogEntry' name_descriptor: - pattern: "projects/{project}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Project" parent_name_extractor: "projects/{project}" - pattern: "folders/{folder}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Folder" parent_name_extractor: "folders/{folder}" - pattern: "organizations/{organization}/logs/{log}" parent_type: "cloudresourcemanager.googleapis.com/Organization" parent_name_extractor: "organizations/{organization}" - pattern: "billingAccounts/{billing_account}/logs/{log}" parent_type: "billing.googleapis.com/BillingAccount" parent_name_extractor: "billingAccounts/{billing_account}" For flexible resources, the resource name doesn't contain parent names, but the resource itself has parents for policy evaluation. Example: message Shelf { option (google.api.resource) = { type: "library.googleapis.com/Shelf" name_descriptor: { pattern: "shelves/{shelf}" parent_type: "cloudresourcemanager.googleapis.com/Project" } name_descriptor: { pattern: "shelves/{shelf}" parent_type: "cloudresourcemanager.googleapis.com/Folder" } }; } The ResourceDescriptor Yaml config will look like: resources: - type: 'library.googleapis.com/Shelf' name_descriptor: - pattern: "shelves/{shelf}" parent_type: "cloudresourcemanager.googleapis.com/Project" - pattern: "shelves/{shelf}" parent_type: "cloudresourcemanager.googleapis.com/Folder"

enum ResourceDescriptor.History

resource.proto:157

A description of the historical or future-looking state of the resource pattern.

Used in: ResourceDescriptor

enum ResourceDescriptor.Style

resource.proto:172

A flag representing a specific style that a resource claims to conform to.

Used in: ResourceDescriptor

message ResourceReference

resource.proto:264

Defines a proto annotation that describes a string field that refers to an API resource.

message RoutingParameter

routing.proto:402

A projection from an input message to the GRPC or REST header.

Used in: RoutingRule

message RoutingRule

routing.proto:391

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

message Service

service.proto:71

`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 config_version: 3 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

message SourceInfo

source_info.proto:29

Source information used to create a Service Config

Used in: Service

message SystemParameter

system_parameter.proto:85

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.

Used in: SystemParameterRule

message SystemParameterRule

system_parameter.proto:67

Define a system parameter rule mapping system parameter definitions to methods.

Used in: SystemParameters

message SystemParameters

system_parameter.proto:32

### 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.

Used in: Service

message Usage

usage.proto:29

Configuration controlling usage of a service.

Used in: Service

message UsageRule

usage.proto:76

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

Used in: Usage