Namespace Google.Api (2.2.0)

Classes

Advice

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

AnnotationsExtensions

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

AnnotationsReflection

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

Authentication

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

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.

AuthProvider

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

AuthReflection

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

AuthRequirement

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

Backend

Backend defines the backend configuration for a service.

BackendReflection

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

BackendRule

A backend rule provides configuration for an individual API element.

BackendRule.Types

Container for nested types declared in the BackendRule message type.

Billing

Billing related configuration of the service.

The following example shows how to configure monitored resources and metrics for billing, consumer_destinations is the only supported destination and the monitored resources need at least one label key cloud.googleapis.com/location to indicate the location of the billing usage, using different monitored resources between monitoring and billing is recommended so they can be evolved independently:

monitored_resources:

type: library.googleapis.com/billing_branch labels:
- key: cloud.googleapis.com/location description: | Predefined label to support billing location restriction.
- key: city description: | Custom label to define the city where the library branch is located in.
- key: name description: Custom label to define the name of the library branch. metrics:
name: library.googleapis.com/book/borrowed_count metric_kind: DELTA value_type: INT64 unit: "1" billing: consumer_destinations:
- monitored_resource: library.googleapis.com/billing_branch metrics:
  - library.googleapis.com/book/borrowed_count

Billing.Types

Container for nested types declared in the Billing message type.

Billing.Types.BillingDestination

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

BillingReflection

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

ClientExtensions

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

ClientReflection

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

ConfigChange

Output generated from semantically comparing two versions of a service configuration.

Includes detailed information about a field that have changed with applicable advice about potential consequences for the change, such as backwards-incompatibility.

ConfigChangeReflection

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

ConsumerReflection

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

Context

Context defines which contexts an API requests.

Example:

context: rules:

selector: "*" requested:
- google.rpc.context.ProjectContext
- google.rpc.context.OriginContext

The above specifies that all methods in the API request google.rpc.context.ProjectContext and google.rpc.context.OriginContext.

Available context types are defined in package google.rpc.context.

This also provides mechanism to whitelist any protobuf message extension that can be sent in grpc metadata using “x-goog-ext-<extension_id>-bin” and “x-goog-ext-<extension_id>-jspb” format. For example, list any service specific protobuf types that can appear in grpc metadata as follows in your yaml file:

Example:

context: rules:

selector: "google.example.library.v1.LibraryService.CreateBook" allowed_request_extensions:
- google.foo.v1.NewExtension allowed_response_extensions:
- google.foo.v1.NewExtension

You can also specify extension ID instead of fully qualified extension name here.

ContextReflection

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

ContextRule

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

Control

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

ControlReflection

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

CustomHttpPattern

A custom pattern is used for defining custom HTTP verb.

Distribution

Distribution contains summary statistics for a population of values. It optionally contains a histogram representing the distribution of those values across a set of buckets.

The summary statistics are the count, mean, sum of the squared deviation from the mean, the minimum, and the maximum of the set of population of values. The histogram is based on a sequence of buckets and gives a count of values that fall into each bucket. The boundaries of the buckets are given either explicitly or by formulas for buckets of fixed or exponentially increasing widths.

Although it is not forbidden, it is generally a bad idea to include non-finite values (infinities or NaNs) in the population of values, as this will render the mean and sum_of_squared_deviation fields meaningless.

Distribution.Types

Container for nested types declared in the Distribution message type.

Distribution.Types.BucketOptions

BucketOptions describes the bucket boundaries used to create a histogram for the distribution. The buckets can be in a linear sequence, an exponential sequence, or each bucket can be specified explicitly. BucketOptions does not include the number of values in each bucket.

A bucket has an inclusive lower bound and exclusive upper bound for the values that are counted for that bucket. The upper bound of a bucket must be strictly greater than the lower bound. The sequence of N buckets for a distribution consists of an underflow bucket (number 0), zero or more finite buckets (number 1 through N - 2) and an overflow bucket (number N - 1). The buckets are contiguous: the lower bound of bucket i (i > 0) is the same as the upper bound of bucket i - 1. The buckets span the whole range of finite values: lower bound of the underflow bucket is -infinity and the upper bound of the overflow bucket is +infinity. The finite buckets are so-called because both bounds are finite.

Distribution.Types.BucketOptions.Types

Container for nested types declared in the BucketOptions message type.

Distribution.Types.BucketOptions.Types.Explicit

Specifies a set of buckets with arbitrary widths.

There are size(bounds) + 1 (= N) buckets. Bucket i has the following boundaries:

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

The bounds field must contain at least one element. If bounds has only one element, then there are no finite buckets, and that single element is the common boundary of the overflow and underflow buckets.

Distribution.Types.BucketOptions.Types.Exponential

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

There are num_finite_buckets + 2 (= N) buckets. Bucket i has the following boundaries:

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

Distribution.Types.BucketOptions.Types.Linear

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

There are num_finite_buckets + 2 (= N) buckets. Bucket i has the following boundaries:

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

Distribution.Types.Exemplar

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

Distribution.Types.Range

The range of the population values.

DistributionReflection

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

Documentation

Documentation provides the information for describing a service.

Example: <pre><code>documentation: summary: > The Google Calendar API gives access to most calendar features. pages:

name: Overview content: (== include google/foo/overview.md ==)
name: Tutorial content: (== include google/foo/tutorial.md ==) subpages;
name: Java content: (== include google/foo/tutorial_java.md ==) rules:
selector: google.calendar.Calendar.Get description: > ...
selector: google.calendar.Calendar.Put description: > ... </code></pre> Documentation is provided in markdown syntax. In addition to standard markdown features, definition lists, tables and fenced code blocks are supported. Section headers can be provided and are interpreted relative to the section nesting of the context where a documentation fragment is embedded.

Documentation from the IDL is merged with documentation defined via the config at normalization time, where documentation provided by config rules overrides IDL provided.

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

In order to reference a proto element, the following notation can be used: <pre><code>[fully.qualified.proto.name][]</code></pre> To override the display text used for the link, this can be used: <pre><code>[display text][fully.qualified.proto.name]</code></pre> Text can be excluded from doc using the following notation: <pre><code>(-- internal comment --)</code></pre>

A few directives are available in documentation. Note that directives must appear on a single line to be properly identified. The include directive includes a markdown file from an external source: <pre><code>(== include path/to/file ==)</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>(== resource_for v1.shelves.books ==)</code></pre> The directive suppress_warning does not directly affect documentation and is documented together with service config validation.

DocumentationReflection

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

DocumentationRule

A documentation rule provides information about individual API elements.

Endpoint

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

EndpointReflection

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

FieldBehaviorExtensions

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

FieldBehaviorReflection

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

Http

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.

HttpBody

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

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

It can be used as a top-level request field, which is convenient if one wants to extract parameters from either the URL or HTTP template into the request fields and also want access to the raw HTTP body.

Example:

message GetResourceRequest { // A unique request id. string request_id = 1;

// The raw HTTP body is bound to this field. google.api.HttpBody http_body = 2; }

service ResourceService { rpc GetResource(GetResourceRequest) returns (google.api.HttpBody); rpc UpdateResource(google.api.HttpBody) returns (google.protobuf.Empty); }

Example with streaming methods:

service CaldavService { rpc GetCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); rpc UpdateCalendar(stream google.api.HttpBody) returns (stream google.api.HttpBody); }

Use of this type only changes how the request and response bodies are handled, all other features will continue to work unchanged.

HttpbodyReflection

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

HttpReflection

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

HttpRule

gRPC Transcoding

gRPC Transcoding is a feature for mapping between a gRPC method and one or more HTTP REST endpoints. It allows developers to build a single API service that supports both gRPC APIs and REST APIs. Many systems, including Google APIs, Cloud Endpoints, gRPC Gateway, and Envoy proxy support this feature and use it for large scale production services.

HttpRule defines the schema of the gRPC/REST mapping. The mapping specifies how different portions of the gRPC request message are mapped to the URL path, URL query parameters, and HTTP request body. It also controls how the gRPC response message is mapped to the HTTP response body. HttpRule is typically specified as an google.api.http annotation on the gRPC method.

Each mapping specifies a URL path template and an HTTP method. The path template may refer to one or more fields in the gRPC request message, as long as each field is a non-repeated field with a primitive (non-message) type. The path template controls how fields of the request message are mapped to the URL path.

Example:

service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) = { get: "/v1/{name=messages/*}" }; } } message GetMessageRequest { string name = 1; // Mapped to URL path. } message Message { string text = 1; // The resource content. }

This enables an HTTP REST to gRPC mapping as below:

HTTP	gRPC
`GET /v1/messages/123456`	`GetMessage(name: "messages/123456")`

Any fields in the request message which are not bound by the path template automatically become HTTP query parameters if there is no HTTP request body. For example:

service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) = { get:"/v1/messages/{message_id}" }; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // Mapped to URL path. int64 revision = 2; // Mapped to URL query parameter revision. SubMessage sub = 3; // Mapped to URL query parameter sub.subfield. }

This enables a HTTP JSON to RPC mapping as below:

HTTP	gRPC
`GET /v1/messages/123456?revision=2&sub.subfield=foo`

GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))

Note that fields which are mapped to URL query parameters must have a primitive type or a repeated primitive type or a non-repeated message type. In the case of a repeated type, the parameter can be repeated in the URL as ...?param=A&param=B. In the case of a message type, each field of the message is mapped to a separate parameter, such as ...?foo.a=A&foo.b=B&foo.c=C.

For HTTP methods that allow a request body, the body field specifies the mapping. Consider a REST update method on the message resource collection:

service Messaging { rpc UpdateMessage(UpdateMessageRequest) returns (Message) { option (google.api.http) = { patch: "/v1/messages/{message_id}" body: "message" }; } } message UpdateMessageRequest { string message_id = 1; // mapped to the URL Message message = 2; // mapped to the body }

The following HTTP JSON to RPC mapping is enabled, where the representation of the JSON in the request body is determined by protos JSON encoding:

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

"123456" message { text: "Hi!" })`

The special name * can be used in the body mapping to define that every field not bound by the path template should be mapped to the request body. This enables the following alternative definition of the update method:

service Messaging { rpc UpdateMessage(Message) returns (Message) { option (google.api.http) = { patch: "/v1/messages/{message_id}" body: "*" }; } } message Message { string message_id = 1; string text = 2; }

The following HTTP JSON to RPC mapping is enabled:

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

"123456" text: "Hi!")`

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

It is possible to define multiple HTTP methods for one RPC by using the additional_bindings option. Example:

service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) = { get: "/v1/messages/{message_id}" additional_bindings { get: "/v1/users/{user_id}/messages/{message_id}" } }; } } message GetMessageRequest { string message_id = 1; string user_id = 2; }

This enables the following two alternative HTTP JSON to RPC mappings:

HTTP	gRPC
`GET /v1/messages/123456`	`GetMessage(message_id: "123456")`
`GET /v1/users/me/messages/123456`	`GetMessage(user_id: "me" message_id:

"123456")`

Rules for HTTP mapping

Leaf request fields (recursive expansion nested messages in the request message) are classified into three categories:
Fields referred by the path template. They are passed via the URL path.
Fields referred by the [HttpRule.body][google.api.HttpRule.body]. They are passed via the HTTP request body.
All other fields are passed via the URL query parameters, and the parameter name is the field path in the request message. A repeated field can be represented as multiple query parameters under the same name.
If [HttpRule.body][google.api.HttpRule.body] is "*", there is no URL query parameter, all fields are passed via URL path and HTTP request body.
If [HttpRule.body][google.api.HttpRule.body] is omitted, there is no HTTP request body, all fields are passed via URL path and URL query parameters.

Path template syntax

Template = "/" Segments [ Verb ] ; Segments = Segment { "/" Segment } ; Segment = "" | "*" | LITERAL | Variable ; Variable = "{" FieldPath [ "=" Segments ] "}" ; FieldPath = IDENT { "." IDENT } ; Verb = ":" LITERAL ;

The syntax * matches a single URL path segment. The syntax ** matches zero or more URL path segments, which must be the last part of the URL path except the Verb.

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=*}.

The syntax LITERAL matches literal text in the URL path. If the LITERAL contains any reserved character, such characters should be percent-encoded before the matching.

If a variable contains exactly one path segment, such as "{var}" or "{var=*}", when such a variable is expanded into a URL path on the client side, all characters except [-_.~0-9a-zA-Z] are percent-encoded. The server side does the reverse decoding. Such variables show up in the Discovery Document as {var}.

If a variable contains multiple path segments, such as "{var=foo/*}" or "{var=**}", when such a variable is expanded into a URL path on the client side, all characters except [-_.~/0-9a-zA-Z] are percent-encoded. The server side does the reverse decoding, except "%2F" and "%2f" are left unchanged. Such variables show up in the Discovery Document as {+var}.

Using gRPC API Service Configuration

gRPC API Service Configuration (service config) is a configuration language for configuring a gRPC service to become a user-facing product. The service config is simply the YAML representation of the google.api.Service proto message.

As an alternative to annotating your proto file, you can configure gRPC transcoding in your service config YAML files. You do this by specifying a HttpRule that maps the gRPC method to a REST endpoint, achieving the same effect as the proto annotation. This can be particularly useful if you have a proto that is reused in multiple services. Note that any transcoding specified in the service config will override any matching transcoding configuration in the proto.

Example:

http: rules:

Selects a gRPC method and applies HttpRule to it.

selector: example.v1.Messaging.GetMessage get: /v1/messages/{message_id}/{sub.subfield}

Special notes

When gRPC Transcoding is used to map a gRPC to JSON REST endpoints, the proto to JSON conversion must follow the proto3 specification.

While the single segment variable follows the semantics of RFC 6570 Section 3.2.2 Simple String Expansion, the multi segment variable does not follow RFC 6570 Section 3.2.3 Reserved Expansion. The reason is that the Reserved Expansion does not expand special characters like ? and #, which would lead to invalid URLs. As the result, gRPC Transcoding uses a custom encoding for multi segment variables.

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

The path variables must not capture the leading "/" character. The reason is that the most common use case "{var}" does not capture the leading "/" character. For consistency, all path variables must share the same behavior.

Repeated message fields must not be mapped to URL query parameters, because no client library can support such complicated mapping.

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

JwtLocation

Specifies a location to extract JWT from an API request.

LabelDescriptor

A description of a label.

LabelDescriptor.Types

Container for nested types declared in the LabelDescriptor message type.

LabelReflection

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

LaunchStageReflection

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

LogDescriptor

A description of a log type. Example in YAML format:

name: library.googleapis.com/activity_history description: The history of borrowing and returning library items. display_name: Activity labels:
- key: /customer_id description: Identifier of a library customer

Logging

Logging configuration of the service.

The following example shows how to configure logs to be sent to the producer and consumer projects. In the example, the activity_history log is sent to both the producer and consumer projects, whereas the purchase_history log is only sent to the producer project.

monitored_resources:

type: library.googleapis.com/branch labels:
- key: /city description: The city where the library branch is located in.
- key: /name description: The name of the branch. logs:
name: activity_history labels:
- key: /customer_id
name: purchase_history logging: producer_destinations:
- monitored_resource: library.googleapis.com/branch logs:
  - activity_history
  - purchase_history consumer_destinations:
- monitored_resource: library.googleapis.com/branch logs:
  - activity_history

Logging.Types

Container for nested types declared in the Logging message type.

Logging.Types.LoggingDestination

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

LoggingReflection

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

LogReflection

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

Metric

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

MetricDescriptor

Defines a metric type and its schema. Once a metric descriptor is created, deleting or altering it stops data collection and makes the metric type's existing data unusable.

The following are specific rules for service defined Monitoring metric descriptors:

type, metric_kind, value_type, description, display_name, launch_stage fields are all required. The unit field must be specified if the value_type is any of DOUBLE, INT64, DISTRIBUTION.
Maximum of default 500 metric descriptors per service is allowed.
Maximum of default 10 labels per metric descriptor is allowed.

The default maximum limit can be overridden. Please follow https://cloud.google.com/monitoring/quotas

MetricDescriptor.Types

Container for nested types declared in the MetricDescriptor message type.

MetricDescriptor.Types.MetricDescriptorMetadata

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

MetricReflection

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

MetricRule

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

MonitoredResource

An object representing a resource that can be used for monitoring, logging, billing, or other purposes. Examples include virtual machine instances, databases, and storage devices such as disks. The type field identifies a [MonitoredResourceDescriptor][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" }}

MonitoredResourceDescriptor

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 services can support different monitored resource types.

The following are specific rules to service defined monitored resources for Monitoring and Logging:

The type, display_name, description, labels and launch_stage fields are all required.
The first label of the monitored resource descriptor must be resource_container. There are legacy monitored resource descritptors start with project_id.
It must include a location label.
Maximum of default 5 service defined monitored resource descriptors is allowed per service.
Maximum of default 10 labels per monitored resource is allowed.

The default maximum limit can be overridden. Please follow https://cloud.google.com/monitoring/quotas

MonitoredResourceMetadata

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. Monitoring and Logging use an ingestion pipeline to extract metadata for cloud resources of all types, and store the metadata in this message.

MonitoredResourceReflection

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

Monitoring

Monitoring configuration of the service.

The example below shows how to configure monitored resources and metrics for monitoring. In the example, a monitored resource and two metrics are defined. The library.googleapis.com/book/returned_count metric is sent to both producer and consumer projects, whereas the library.googleapis.com/book/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

Monitoring.Types

Container for nested types declared in the Monitoring message type.

Monitoring.Types.MonitoringDestination

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

MonitoringReflection

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

OAuthRequirements

OAuth scopes are a way to define data and permissions on data. For example, there are scopes defined for "Read-only access to Google Calendar" and "Access to Cloud Platform". Users can consent to a scope for an application, giving it permission to access that data on their behalf.

OAuth scope specifications should be fairly coarse grained; a user will need to see and understand the text description of what your scope means.

In most cases: use one or at most two OAuth scopes for an entire family of products. If your product has multiple APIs, you should probably be sharing the OAuth scope across all of those APIs.

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

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

Page

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

ProjectProperties

A descriptor for defining project properties for a service. One service may have many consumer projects, and the service may want to behave differently depending on some properties on the project. For example, a project may be associated with a school, or a business, or a government agency, a business type property on the project may affect how a service responds to the client. This descriptor defines which properties are allowed to be set on a project.

Example:

project_properties: properties:

name: NO_WATERMARK type: BOOL description: Allows usage of the API without watermarks.
name: EXTENDED_TILE_CACHE_PERIOD type: INT64

Property

Defines project properties.

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

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

Property.Types

Container for nested types declared in the Property message type.

Quota

Quota configuration helps to achieve fairness and budgeting in service usage.

The metric based quota configuration works this way:

The service configuration defines a set of metrics.
For API calls, the quota.metric_rules maps methods to metrics with corresponding costs.
The quota.limits defines limits on the metrics, which will be used for quota checks at runtime.

An example quota configuration in yaml format:

quota: limits:

name: apiWriteQpsPerProject metric: library.googleapis.com/write_calls unit: "1/min/{project}" # rate limit for consumer projects values: STANDARD: 10000

The metric rules bind all methods to the read_calls metric,

except for the UpdateBook and DeleteBook methods. These two methods

are mapped to the write_calls metric, with the UpdateBook method

consuming at twice rate as the DeleteBook method.

metric_rules:

selector: "*" metric_costs: library.googleapis.com/read_calls: 1
selector: google.example.library.v1.LibraryService.UpdateBook metric_costs: library.googleapis.com/write_calls: 2
selector: google.example.library.v1.LibraryService.DeleteBook metric_costs: library.googleapis.com/write_calls: 1

Corresponding Metric definition:

metrics:

name: library.googleapis.com/read_calls display_name: Read requests metric_kind: DELTA value_type: INT64
name: library.googleapis.com/write_calls display_name: Write requests metric_kind: DELTA value_type: INT64

QuotaLimit

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

QuotaReflection

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

ResourceDescriptor

A simple descriptor of a resource type.

ResourceDescriptor annotates a resource message (either by means of a protobuf annotation or use in the service config), and associates the resource's schema, the resource type, and the pattern of the resource name.

Example:

message Topic { // Indicates this message defines a resource schema. // Declares the resource type in the format of {service}/{kind}. // For Kubernetes resources, the format is {api group}/{kind}. option (google.api.resource) = { type: "pubsub.googleapis.com/Topic" 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"

ResourceDescriptor.Types

Container for nested types declared in the ResourceDescriptor message type.

ResourceExtensions

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

ResourceReference

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

ResourceReflection

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

Service

Service is the root object of Google service configuration schema. It describes basic information about a service, such as the name and the title, and delegates other aspects to sub-sections. Each sub-section is either a proto message or a repeated proto message that configures a specific aspect, such as auth. See each proto message definition for details.

Example:

type: google.api.Service 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

ServiceReflection

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

SourceInfo

Source information used to create a Service Config

SourceInfoReflection

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

SystemParameter

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

SystemParameterReflection

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

SystemParameterRule

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

SystemParameters

System parameter configuration

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

Usage

Configuration controlling usage of a service.

UsageReflection

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

UsageRule

Usage configuration rules for the service.

NOTE: Under development.

Use this rule to configure unregistered calls for the service. Unregistered calls are calls that do not contain consumer project identity. (Example: calls that do not contain an API key). By default, API methods do not allow unregistered calls, and each method call must be identified by a consumer project identity. Use this rule to allow/disallow unregistered calls.

Example of an API that wants to allow unregistered calls for entire service.

usage: rules:

selector: "*" allow_unregistered_calls: true

Example of a method that wants to allow unregistered calls.

usage: rules:

selector: "google.example.library.v1.LibraryService.CreateBook" allow_unregistered_calls: true

Enums

BackendRule.AuthenticationOneofCase

Enum of possible cases for the "authentication" oneof.

BackendRule.Types.PathTranslation

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

Path Translation is applicable only to HTTP-based backends. Backends which do not accept requests over HTTP/HTTPS should leave path_translation unspecified.

ChangeType

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

Distribution.Types.BucketOptions.OptionsOneofCase

Enum of possible cases for the "options" oneof.

FieldBehavior

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

Note: This enum may receive new values in the future.