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

Holder for extension identifiers generated from the top level of google/api/annotations.proto

Holder for reflection information generated from google/api/annotations.proto

Configuration for an authentication provider, including support forJSON Web Token(JWT).

Holder for reflection information generated from google/api/auth.proto

User-defined authentication requirements, including support forJSON Web Token(JWT).

Authentication defines the authentication configuration for API methodsprovided by an API service.

Example:

name: calendar.googleapis.comauthentication:  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

Authentication rules for the service.

By default, if a method has any authentication requirements, every requestmust include a valid credential matching one of the requirements.It's an error to include more than one kind of credential in a singlerequest.

If a method doesn't have any auth requirements, request credentials will beignored.

Backend defines the backend configuration for a service.

Holder for reflection information generated from google/api/backend.proto

A backend rule provides configuration for an individual API element.

Container for nested types declared in the BackendRule message type.

Billing related configuration of the service.

The following example shows how to configure monitored resources and metricsfor billing,consumer_destinations is the only supported destination andthe monitored resources need at least one label keycloud.googleapis.com/location to indicate the location of the billingusage, using different monitored resources between monitoring and billing isrecommended 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

Container for nested types declared in the Billing message type.

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

Holder for reflection information generated from google/api/billing.proto

Holder for extension identifiers generated from the top level of google/api/client.proto

Details about how and where to publish client libraries.

Holder for reflection information generated from google/api/client.proto

Required information for every language.

Output generated from semantically comparing two versions of a serviceconfiguration.

Includes detailed information about a field that have changed withapplicable advice about potential consequences for the change, such asbackwards-incompatibility.

Holder for reflection information generated from google/api/config_change.proto

Holder for reflection information generated from google/api/consumer.proto

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 requestgoogle.rpc.context.ProjectContext andgoogle.rpc.context.OriginContext.

Available context types are defined in packagegoogle.rpc.context.

This also provides mechanism to allowlist any protobuf message extension thatcan be sent in grpc metadata using “x-goog-ext-<extension_id>-bin” and“x-goog-ext-<extension_id>-jspb” format. For example, list any servicespecific protobuf types that can appear in grpc metadata as follows in youryaml 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 namehere.

Holder for reflection information generated from google/api/context.proto

A context rule provides information about the context for an individual APIelement.

Selects and configures the service controller used by the service.

Example:

control:  environment: servicecontrol.googleapis.com

Holder for reflection information generated from google/api/control.proto

Settings for C++ client libraries.

A custom pattern is used for defining custom HTTP verb.

Distribution contains summary statistics for a population of values. Itoptionally contains a histogram representing the distribution of those valuesacross a set of buckets.

The summary statistics are the count, mean, sum of the squared deviation fromthe 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 valuesthat fall into each bucket. The boundaries of the buckets are given eitherexplicitly or by formulas for buckets of fixed or exponentially increasingwidths.

Although it is not forbidden, it is generally a bad idea to includenon-finite values (infinities or NaNs) in the population of values, as thiswill render themean andsum_of_squared_deviation fields meaningless.

Container for nested types declared in the Distribution message type.

BucketOptions describes the bucket boundaries used to create a histogramfor the distribution. The buckets can be in a linear sequence, anexponential 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 thevalues that are counted for that bucket. The upper bound of a bucket mustbe strictly greater than the lower bound. The sequence of N buckets for adistribution consists of an underflow bucket (number 0), zero or morefinite 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 thesame as the upper bound of bucket i - 1. The buckets span the whole rangeof finite values: lower bound of the underflow bucket is -infinity and theupper bound of the overflow bucket is +infinity. The finite buckets areso-called because both bounds are finite.

Container for nested types declared in the BucketOptions message type.

Specifies a set of buckets with arbitrary widths.

There aresize(bounds) + 1 (= N) buckets. Bucketi has the followingboundaries:

Upper bound (0 <= i < N-1): bounds[i] Lower bound (1 <= i < N); bounds[i - 1]

Thebounds field must contain at least one element. Ifbounds hasonly one element, then there are no finite buckets, and that singleelement is the common boundary of the overflow and underflow buckets.

Specifies an exponential sequence of buckets that have a width that isproportional to the value of the lower bound. Each bucket represents aconstant relative uncertainty on a specific value in the bucket.

There arenum_finite_buckets + 2 (= N) buckets. Bucketi has thefollowing boundaries:

Upper bound (0 <= i < N-1): scale * (growth_factor ^ i).

Lower bound (1 <= i < N): scale * (growth_factor ^ (i - 1)).

Specifies a linear sequence of buckets that all have the same width(except overflow and underflow). Each bucket represents a constantabsolute uncertainty on the specific value in the bucket.

There arenum_finite_buckets + 2 (= N) buckets. Bucketi has thefollowing boundaries:

Upper bound (0 <= i < N-1): offset + (width * i).

Lower bound (1 <= i < N): offset + (width * (i - 1)).

Exemplars are example points that may be used to annotate aggregateddistribution values. They are metadata that gives information about aparticular value added to a Distribution bucket, such as a trace ID thatwas active when a value was added. They may contain further information,such as a example values and timestamps, origin, etc.

The range of the population values.

Holder for reflection information generated from google/api/distribution.proto

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: Overviewcontent: &#40;== include google/foo/overview.md ==&#41;
• name: Tutorialcontent: &#40;== include google/foo/tutorial.md ==&#41;subpages:
  • name: Javacontent: &#40;== include google/foo/tutorial_java.md ==&#41;rules:
• selector: google.calendar.Calendar.Getdescription: > ...
• selector: google.calendar.Calendar.Putdescription: > ...</code></pre>Documentation is provided in markdown syntax. In addition tostandard markdown features, definition lists, tables and fencedcode blocks are supported. Section headers can be provided and areinterpreted relative to the section nesting of the context wherea documentation fragment is embedded.

Documentation from the IDL is merged with documentation definedvia the config at normalization time, where documentation providedby config rules overrides IDL provided.

A number of constructs specific to the API platform are supportedin documentation text.

In order to reference a proto element, the followingnotation 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 thatdirectives must appear on a single line to be properlyidentified. Theinclude directive includes a markdown file froman external source:<pre><code>&#40;== include path/to/file ==&#41;</code></pre>Theresource_for directive marks a message to be the resource ofa collection in REST view. If it is not specified, tools attemptto infer the resource from the operations in a collection:<pre><code>&#40;== resource_for v1.shelves.books ==&#41;</code></pre>The directivesuppress_warning does not directly affect documentationand is documented together with service config validation.

Holder for reflection information generated from google/api/documentation.proto

A documentation rule provides information about individual API elements.

Settings for Dotnet client libraries.

Endpoint describes a network address of a service that serves a set ofAPIs. It is commonly known as a service endpoint. A service may exposeany number of service endpoints, and all service endpoints share the sameservice definition, such as quota limits and monitoring metrics.

Example:

type: google.api.Servicename: library-example.googleapis.comendpoints:  # Declares network address `https://library-example.googleapis.com`  # for service `library-example.googleapis.com`. The `https` scheme  # is implicit for all service endpoints. Other schemes may be  # supported in the future.- name: library-example.googleapis.com  allow_cors: false- name: content-staging-library-example.googleapis.com  # Allows HTTP OPTIONS calls to be passed to the API frontend, for it  # to decide whether the subsequent cross-origin request is allowed  # to proceed.  allow_cors: true

Holder for reflection information generated from google/api/endpoint.proto

Holder for reflection information generated from google/api/error_reason.proto

Holder for extension identifiers generated from the top level of google/api/field_behavior.proto

Holder for reflection information generated from google/api/field_behavior.proto

Rich semantic information of an API field beyond basic typing.

Container for nested types declared in the FieldInfo message type.

Holder for extension identifiers generated from the top level of google/api/field_info.proto

Holder for reflection information generated from google/api/field_info.proto

Google API Policy Annotation

This message defines a simple API policy annotation that can be used toannotate API request and response message fields with applicable policies.One field may have multiple applicable policies that must all be satisfiedbefore a request can be processed. This policy annotation is used togenerate the overall policy that will be used for automatic runtimepolicy enforcement and documentation generation.

Settings for Go client libraries.

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

Message that represents an arbitrary HTTP body. It should only be used forpayload formats that can't be represented as JSON, such as raw binary oran HTML page.

This message can be used both in streaming and non-streaming API methods inthe request as well as the response.

It can be used as a top-level request field, which is convenient if onewants to extract parameters from either the URL or HTTP template into therequest 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 arehandled, all other features will continue to work unchanged.

Holder for reflection information generated from google/api/http.proto

gRPC Transcoding

gRPC Transcoding is a feature for mapping between a gRPC method and one ormore HTTP REST endpoints. It allows developers to build a single API servicethat supports both gRPC APIs and REST APIs. Many systems, includingGoogleAPIs,Cloud Endpoints,gRPCGateway,andEnvoy proxy support this featureand use it for large scale production services.

HttpRule defines the schema of the gRPC/REST mapping. The mapping specifieshow different portions of the gRPC request message are mapped to the URLpath, URL query parameters, and HTTP request body. It also controls how thegRPC response message is mapped to the HTTP response body.HttpRule istypically specified as angoogle.api.http annotation on the gRPC method.

Each mapping specifies a URL path template and an HTTP method. The pathtemplate may refer to one or more fields in the gRPC request message, as longas 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 tothe 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:GET /v1/messages/123456
• gRPC:GetMessage(name: "messages/123456")

Any fields in the request message which are not bound by the path templateautomatically 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:GET /v1/messages/123456?revision=2&sub.subfield=foo
• gRPC:GetMessage(message_id: "123456" revision: 2 sub:SubMessage(subfield: "foo"))

Note that fields which are mapped to URL query parameters must have aprimitive 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 URLas...?param=A&param=B. In the case of a message type, each field of themessage 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, thebody fieldspecifies the mapping. Consider a REST update method on themessage 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 therepresentation of the JSON in the request body is determined byprotos JSON encoding:

• HTTP:PATCH /v1/messages/123456 { "text": "Hi!" }
• gRPC:UpdateMessage(message_id: "123456" message { text: "Hi!" })

The special name* can be used in the body mapping to define thatevery field not bound by the path template should be mapped to therequest body. This enables the following alternative definition ofthe 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:PATCH /v1/messages/123456 { "text": "Hi!" }
• gRPC:UpdateMessage(message_id: "123456" text: "Hi!")

Note that when using* in the body mapping, it is not possible tohave HTTP parameters, as all fields not bound by the path end inthe body. This makes this option more rarely used in practice whendefining REST APIs. The common usage of* is in custom methodswhich don't use the URL at all for transferring data.

It is possible to define multiple HTTP methods for one RPC by usingtheadditional_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:GET /v1/messages/123456

• gRPC:GetMessage(message_id: "123456")

• HTTP:GET /v1/users/me/messages/123456

• gRPC:GetMessage(user_id: "me" message_id: "123456")

Rules for HTTP mapping

1. Leaf request fields (recursive expansion nested messages in the requestmessage) are classified into three categories:
   • Fields referred by the path template. They are passed via the URL path.
   • Fields referred by the [HttpRule.body][google.api.HttpRule.body]. Theyare passed via the HTTPrequest body.
   • All other fields are passed via the URL query parameters, and theparameter name is the field path in the request message. A repeatedfield can be represented as multiple query parameters under the samename.
   • If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URLquery parameter, all fieldsare passed via URL path and HTTP request body.
   • If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTPrequest body, allfields 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 syntax** matcheszero or more URL path segments, which must be the last part of the URL pathexcept theVerb.

The syntaxVariable matches part of the URL path as specified by itstemplate. A variable template must not contain other variables. If a variablematches a single path segment, its template may be omitted, e.g.{var}is equivalent to{var=*}.

The syntaxLITERAL matches literal text in the URL path. If theLITERALcontains any reserved character, such characters should be percent-encodedbefore 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 clientside, all characters except[-_.~0-9a-zA-Z] are percent-encoded. Theserver side does the reverse decoding. Such variables show up in theDiscoveryDocument 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 theclient side, all characters except[-_.~/0-9a-zA-Z] are percent-encoded.The server side does the reverse decoding, except "%2F" and "%2f" are leftunchanged. Such variables show up in theDiscoveryDocument as{+var}.

Using gRPC API Service Configuration

gRPC API Service Configuration (service config) is a configuration languagefor configuring a gRPC service to become a user-facing product. Theservice config is simply the YAML representation of thegoogle.api.Serviceproto message.

As an alternative to annotating your proto file, you can configure gRPCtranscoding in your service config YAML files. You do this by specifying aHttpRule that maps the gRPC method to a REST endpoint, achieving the sameeffect as the proto annotation. This can be particularly useful if youhave a proto that is reused in multiple services. Note that any transcodingspecified in the service config will override any matching transcodingconfiguration in the proto.

The following example selects a gRPC method and applies anHttpRule to it:

http:  rules:    - 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, theproto to JSON conversion must follow theproto3specification.

While the single segment variable follows the semantics ofRFC 6570 Section 3.2.2 Simple StringExpansion, the multi segment variabledoes not follow RFC 6570 Section3.2.3 Reserved Expansion. The reason is that the Reserved Expansiondoes not expand special characters like? and#, which would leadto invalid URLs. As the result, gRPC Transcoding uses a custom encodingfor multi segment variables.

The path variablesmust not refer to any repeated or mapped field,because client libraries are not capable of handling such variable expansion.

The path variablesmust not capture the leading "/" character. The reasonis 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, becauseno client library can support such complicated mapping.

If an API needs to use a JSON array for request or response body, it can mapthe request or response body to a repeated field. However, some gRPCTranscoding implementations may not support this feature.

Holder for reflection information generated from google/api/httpbody.proto

Settings for Java client libraries.

Specifies a location to extract JWT from an API request.

A description of a label.

Container for nested types declared in the LabelDescriptor message type.

Holder for reflection information generated from google/api/label.proto

Holder for reflection information generated from google/api/launch_stage.proto

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

Holder for reflection information generated from google/api/log.proto

Logging configuration of the service.

The following example shows how to configure logs to be sent to theproducer and consumer projects. In the example, theactivity_historylog is sent to both the producer and consumer projects, whereas thepurchase_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_historylogging:  producer_destinations:  - monitored_resource: library.googleapis.com/branch    logs:    - activity_history    - purchase_history  consumer_destinations:  - monitored_resource: library.googleapis.com/branch    logs:    - activity_history

Container for nested types declared in the Logging message type.

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

Holder for reflection information generated from google/api/logging.proto

Defines policies applying to an RPC method.

Describes the generator configuration for a method.

Container for nested types declared in the MethodSettings message type.

Describes settings to use when generating API methods that use thelong-running operation pattern.All default values below are from those used in the client librarygenerators (e.g.Java).

A specific metric, identified by specifying values for all of thelabels of a [MetricDescriptor][google.api.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'sexisting data unusable.

Container for nested types declared in the MetricDescriptor message type.

Additional annotations that can be used to guide the usage of a metric.

Container for nested types declared in the MetricDescriptorMetadata message type.

Holder for reflection information generated from google/api/metric.proto

Bind API methods to metrics. Binding a method to a metric causes thatmetric's configured quota behaviors to apply to the method call.

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. Thetype field identifies a[MonitoredResourceDescriptor][google.api.MonitoredResourceDescriptor] objectthat describes the resource's schema. Information in thelabels fieldidentifies the actual resource and its attributes according to the schema.For example, a particular Compute Engine VM instance could be represented bythe following object, because the[MonitoredResourceDescriptor][google.api.MonitoredResourceDescriptor] for"gce_instance" has labels"project_id","instance_id" and"zone":

{ "type": "gce_instance",  "labels": { "project_id": "my-project",              "instance_id": "12345678901234",              "zone": "us-central1-a" }}

An object that describes the schema of a[MonitoredResource][google.api.MonitoredResource] object using a type nameand a set of labels. For example, the monitored resource descriptor forGoogle 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 generallyprovide alist method that returns the monitored resource descriptors usedby the API.

Auxiliary metadata for a [MonitoredResource][google.api.MonitoredResource]object. [MonitoredResource][google.api.MonitoredResource] objects contain theminimum set of information to uniquely identify a monitored resourceinstance. There is some other useful auxiliary metadata. Monitoring andLogging use an ingestion pipeline to extract metadata for cloud resources ofall types, and store the metadata in this message.

Holder for reflection information generated from google/api/monitored_resource.proto

Monitoring configuration of the service.

The example below shows how to configure monitored resources and metricsfor monitoring. In the example, a monitored resource and two metrics aredefined. Thelibrary.googleapis.com/book/returned_count metric is sentto both producer and consumer projects, whereas thelibrary.googleapis.com/book/num_overdue metric is only sent to theconsumer 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

Container for nested types declared in the Monitoring message type.

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

Holder for reflection information generated from google/api/monitoring.proto

Settings for Node client libraries.

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 needto 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 ofproducts. If your product has multiple APIs, you should probably be sharingthe OAuth scope across all of those APIs.

When you need finer grained OAuth consent screens: talk with your productmanagement about how developers will use them in practice.

Please note that even though each of the canonical scopes is enough for arequest to be accepted and passed to the backend, a request can still faildue to the backend requiring additional scopes or permissions.

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

Settings for Php client libraries.

Holder for extension identifiers generated from the top level of google/api/policy.proto

Holder for reflection information generated from google/api/policy.proto

A descriptor for defining project properties for a service. One service mayhave many consumer projects, and the service may want to behave differentlydepending on some properties on the project. For example, a project may beassociated with a school, or a business, or a government agency, a businesstype 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_WATERMARKtype: BOOLdescription: Allows usage of the API without watermarks.
• name: EXTENDED_TILE_CACHE_PERIODtype: INT64

Defines project properties.

API services can define properties that can be assigned to consumer projectsso that backends can perform response customization without having to makeadditional calls or maintain additional storage. For example, Maps APIdefines properties that controls map tile cache period, or whether to embed awatermark in a result.

These values can be set via API producer console. Only API providers candefine and set these properties.

Container for nested types declared in the Property message type.

This message configures the settings for publishingGoogle Cloud Clientlibrariesgenerated from the service config.

Settings for Python client libraries.

Container for nested types declared in the PythonSettings message type.

Experimental features to be included during client library generation.These fields will be deprecated once the feature graduates and is enabledby default.

Quota configuration helps to achieve fairness and budgeting in serviceusage.

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 withcorresponding costs.
• The quota.limits defines limits on the metrics, which will be used forquota 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

QuotaLimit defines a specific limit that applies over a specified durationfor a limit type. There can be at most one limit for a duration and limittype combination defined within aQuotaGroup.

Holder for reflection information generated from google/api/quota.proto

A simple descriptor of a resource type.

ResourceDescriptor annotates a resource message (either by means of aprotobuf annotation or use in the service config), and associates theresource'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 canlive 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}"

Container for nested types declared in the ResourceDescriptor message type.

Holder for extension identifiers generated from the top level of google/api/resource.proto

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

Holder for reflection information generated from google/api/resource.proto

Holder for extension identifiers generated from the top level of google/api/routing.proto

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

Holder for reflection information generated from google/api/routing.proto

Specifies the routing information that should be sent along with the requestin 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 keyand value must be percent-encoded, and joined together in the format ofkey1=value1&key2=value2.The examples below skip the percent-encoding for readability.

Example 1

Extracting a field from the request to put into the routing headerunchanged, 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 headerunchanged, 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 routingheader, 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 purposeof 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 arespecified. 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 atemplate 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 matchingseveral conflictingly named path templates on (parts of) a single requestfield. 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 matchingseveral non-conflicting path templates on (parts of) a single request field.

Sub-example 6a

Make the templates strict, so that if thetable_name does nothave 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 thetable_name does nothave 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 instanceinformation):

x-goog-request-params:project_id=projects/proj_foo&instance_id=instances/instance_bar

Example 7

Extracting multiple routing header key-value pairs by matchingseveral path templates on multiple request fields.

NB: note that here there is no way to specify sending nothing if one of thefields does not match its template. E.g. if thetable_name is in the wrongformat, theproject_id will not be sent, but therouting_id will be.The backend routing code has to be aware of that and be prepared to notreceive 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 matchingseveral conflictingly named path templates on several request fields. Thelast 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

Settings for Ruby client libraries.

This message is used to configure the generation of a subset of the RPCs ina service for client libraries.

Service is the root object of Google API service configuration (serviceconfig). It describes the basic information about a logical service,such as the service name and the user-facing title, and delegates otheraspects to sub-sections. Each sub-section is either a proto message or arepeated proto message that configures a specific aspect, such as auth.For more information, see each proto message definition.

Example:

type: google.api.Servicename: calendar.googleapis.comtitle: Google Calendar APIapis:- name: google.calendar.v3.Calendarvisibility:  rules:  - selector: "google.calendar.v3.*"    restriction: PREVIEWbackend:  rules:  - selector: "google.calendar.v3.*"    address: calendar.example.comauthentication:  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

Holder for reflection information generated from google/api/service.proto

Source information used to create a Service Config

Holder for reflection information generated from google/api/source_info.proto

Define a parameter's name and location. The parameter may be passed as eitheran HTTP header or a URL query parameter, and if both are passed the behavioris implementation-dependent.

Holder for reflection information generated from google/api/system_parameter.proto

Define a system parameter rule mapping system parameter definitions tomethods.

System parameter configuration

A system parameter is a special kind of parameter defined by the APIsystem, not by an individual API. It is typically mapped to an HTTP headerand/or a URL query parameter. This configuration specifies which methodschange the names of the system parameters.

A reference to a message type, for use in [FieldInfo][google.api.FieldInfo].

Configuration controlling usage of a service.

Holder for reflection information generated from google/api/usage.proto

Usage configuration rules for the service.

NOTE: Under development.

Use this rule to configure unregistered calls for the service. Unregisteredcalls 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 callmust be identified by a consumer project identity. Use this rule toallow/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

Visibility restricts service consumer's access to service elements,such as whether an application can call a visibility-restricted method.The restriction is expressed by applying visibility labels on serviceelements. The visibility labels are elsewhere linked to service consumers.

A service can define multiple visibility labels, but a service consumershould be granted at most one visibility label. Multiple visibilitylabels for a single service consumer are not supported.

If an element and all its parents have no visibility label, its visibilityis 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 methodsEnhancedSearch and Delegate.

Holder for extension identifiers generated from the top level of google/api/visibility.proto

Holder for reflection information generated from google/api/visibility.proto

A visibility rule provides visibility configuration for an individual APIelement.

Enum of possible cases for the "authentication" oneof.

Path Translation specifies how to combine the backend address with therequest path in order to produce the appropriate forwarding URL for therequest.

Path Translation is applicable only to HTTP-based backends. Backends whichdo not accept requests over HTTP/HTTPS should leavepath_translationunspecified.

Classifies set of possible modifications to an object in the serviceconfiguration.

To where should client libraries be published?

The organization for which the client libraries are being published.Affects the url where generated docs are published, etc.

Enum of possible cases for the "options" oneof.

Defines the supported values forgoogle.rpc.ErrorInfo.reason for thegoogleapis.com error domain. This error domain is reserved forServiceInfrastructure.For each error info of this domain, the metadata key "service" refers to thelogical identifier of an API service, such as "pubsub.googleapis.com". The"consumer" refers to the entity that consumes an API Service. It typically isa Google project that owns the client application or the server resource,such as "projects/123". Other metadata keys are specific to each errorreason. For more information, see the definition of the specific errorreason.

An indicator of the behavior of a given field (for example, that a fieldis required in requests, or given as output but ignored as input).Thisdoes not change the behavior in protocol buffers itself; it onlydenotes the behavior and may affect how API tooling handles the field.

Note: This enummay receive new values in the future.

The standard format of a field value. The supported formats are all backedby either an RFC defined by the IETF or a Google-defined AIP.

Enum of possible cases for the "pattern" oneof.

Enum of possible cases for the "in" oneof.

Value types that can be used as label values.

The launch stage as defined byGoogle Cloud PlatformLaunch Stages.

The resource hierarchy level of the timeseries data of a metric.

The kind of measurement. It describes how the data is reported.For information on setting the start time and end time based onthe MetricKind, see [TimeInterval][google.monitoring.v3.TimeInterval].

The value type of a metric.

Supported data type of the property values

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

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