Advice | Generated advice about this change, used for providing more information
about how a change will affect the existing service.
|
Api | Api is a light-weight descriptor for an API Interface. Interfaces are also
described as "protocol buffer services" in some contexts, such as by the
"service" keyword in a .proto file, but they are different from API Services,
which represent a concrete implementation of an interface as opposed to
simply a description of methods and bindings. They are also sometimes simply
referred to as "APIs" in other contexts, such as the name of this message
itself. See https://cloud.google.com/apis/design/glossary for detailed
terminology.
|
AuditConfig | Specifies the audit configuration for a service. The configuration
determines which permission types are logged, and what identities, if any,
are exempted from logging. An AuditConfig must have one or more
AuditLogConfigs. If there are AuditConfigs for both allServices and a
specific service, the union of the two AuditConfigs is used for that service:
the log_types specified in each AuditConfig are enabled, and the
exempted_members in each AuditLogConfig are exempted. Example Policy with
multiple AuditConfigs: { "audit_configs": [ { "service": "allServices",
"audit_log_configs": [ { "log_type": "DATA_READ", "exempted_members": [
"user:jose@example.com" ] }, { "log_type": "DATA_WRITE" }, { "log_type":
"ADMIN_READ" } ] }, { "service": "sampleservice.googleapis.com",
"audit_log_configs": [ { "log_type": "DATA_READ" }, { "log_type":
"DATA_WRITE", "exempted_members": [ "user:aliya@example.com" ] } ] } ] } For
sampleservice, this policy enables DATA_READ, DATA_WRITE and ADMIN_READ
logging. It also exempts jose@example.com from DATA_READ logging, and
aliya@example.com from DATA_WRITE logging.
|
AuditLogConfig | Provides the configuration for logging a type of permissions. Example: {
"audit_log_configs": [ { "log_type": "DATA_READ", "exempted_members": [
"user:jose@example.com" ] }, { "log_type": "DATA_WRITE" } ] } This enables
'DATA_READ' and 'DATA_WRITE' logging, while exempting jose@example.com from
DATA_READ logging.
|
Authentication | Authentication defines the authentication configuration for API methods
provided by an API service. Example: name: calendar.googleapis.com
authentication: providers: - id: google_calendar_auth jwks_uri:
https://www.googleapis.com/oauth2/v1/certs issuer:
https://securetoken.google.com rules: - selector: "*" requirements:
provider_id: google_calendar_auth - selector: google.calendar.Delegate oauth:
canonical_scopes: https://www.googleapis.com/auth/calendar.read
|
AuthenticationRule | Authentication rules for the service. By default, if a method has any
authentication requirements, every request must include a valid credential
matching one of the requirements. It's an error to include more than one kind
of credential in a single request. If a method doesn't have any auth
requirements, request credentials will be ignored.
|
AuthProvider | Configuration for an authentication provider, including support for JSON
Web Token
(JWT).
|
AuthRequirement | User-defined authentication requirements, including support for JSON Web
Token (JWT).
|
Backend | Backend defines the backend configuration for a service.
|
BackendRule | A backend rule provides configuration for an individual API element.
|
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
|
BillingDestination | Configuration of a specific billing destination (Currently only support bill
against consumer project).
|
Binding | Associates members , or principals, with a role .
|
ChangeReport | Change report associated with a particular service configuration. It
contains a list of ConfigChanges based on the comparison between two service
configurations.
|
ClientLibrarySettings | Details about how and where to publish client libraries.
|
CommonLanguageSettings | Required information for every language.
|
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.
|
ConfigFile | Generic specification of a source configuration file
|
ConfigRef | Represents a service configuration with its name and id.
|
ConfigSource | Represents a source file which is used to generate the service configuration
defined by google.api.Service .
|
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 allowlist any
protobuf message extension that can be sent in grpc metadata using
“x-goog-ext--bin” and “x-goog-ext--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.
|
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. Example:
control: environment: servicecontrol.googleapis.com
|
CppSettings | Settings for C++ client libraries.
|
CredentialsClient | Defines the root interface for all clients that generate credentials
for calling Google APIs. All clients should implement this interface.
|
CustomError | Customize service error responses. For example, list any service specific
protobuf types that can appear in error detail lists of error responses.
Example: custom_error: types: - google.foo.v1.CustomError -
google.foo.v1.AnotherError
|
CustomErrorRule | A custom error rule.
|
CustomHttpPattern | A custom pattern is used for defining custom HTTP verb.
|
DeleteServiceStrategy | Strategy used to delete a service. This strategy is a placeholder only used
by the system generated rollout to delete a service.
|
Diagnostic | Represents a diagnostic message (error or warning)
|
Documentation | Documentation provides the information for describing a service. Example:
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: > ... 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:
[fully.qualified.proto.name][] To override the display text used for the
link, this can be used: [display text][fully.qualified.proto.name] Text can
be excluded from doc using the following notation: (-- internal comment --) 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: (== include path/to/file
==) 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: (== resource_for
v1.shelves.books ==) The directive suppress_warning does not directly
affect documentation and is documented together with service config
validation.
|
DocumentationRule | A documentation rule provides information about individual API elements.
|
DotnetSettings | Settings for Dotnet client libraries.
|
EnableServiceResponse | Operation payload for EnableService method.
|
Endpoint | Endpoint describes a network address of a service that serves a set of
APIs. It is commonly known as a service endpoint. A service may expose any
number of service endpoints, and all service endpoints share the same service
definition, such as quota limits and monitoring metrics. Example: type:
google.api.Service name: library-example.googleapis.com endpoints: # 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
|
Enum | Enum type definition.
|
EnumValue | Enum value definition.
|
Expr | Represents a textual expression in the Common Expression Language (CEL)
syntax. CEL is a C-like expression language. The syntax and semantics of CEL
are documented at https://github.com/google/cel-spec. Example (Comparison):
title: "Summary size limit" description: "Determines if a summary is less
than 100 chars" expression: "document.summary.size() < 100" Example
(Equality): title: "Requestor is owner" description: "Determines if requestor
is the document owner" expression: "document.owner ==
request.auth.claims.email" Example (Logic): title: "Public documents"
description: "Determine whether the document should be publicly visible"
expression: "document.type != 'private' && document.type != 'internal'"
Example (Data Manipulation): title: "Notification string" description:
"Create a notification string with a timestamp." expression: "'New message
received at ' + string(document.create_time)" The exact variables and
functions that may be referenced within an expression are determined by the
service that evaluates it. See the service documentation for additional
information.
|
Field | A single field of a message type.
|
FieldPolicy | Google API Policy Annotation This message defines a simple API policy
annotation that can be used to annotate API request and response message
fields with applicable policies. One field may have multiple applicable
policies that must all be satisfied before a request can be processed. This
policy annotation is used to generate the overall policy that will be used
for automatic runtime policy enforcement and documentation generation.
|
FlowErrorDetails | Encapsulation of flow-specific error details for debugging. Used as a
details field on an error Status, not intended for external use.
|
GenerateConfigReportRequest | Request message for GenerateConfigReport method.
|
GenerateConfigReportResponse | Response message for GenerateConfigReport method.
|
GetIamPolicyRequest | Request message for GetIamPolicy method.
|
GetPolicyOptions | Encapsulates settings provided to GetIamPolicy.
|
GoSettings | Settings for Go client libraries.
|
Http | Defines the HTTP configuration for an API service. It contains a list of
HttpRule, each specifying the mapping of an RPC method to one or more HTTP
REST API methods.
|
HttpRule | gRPC Transcoding gRPC Transcoding is a feature for mapping between a gRPC
method and one or more HTTP REST endpoints. It allows developers to build a
single API service that supports both gRPC APIs and REST APIs. Many systems,
including Google APIs, Cloud
Endpoints, gRPC
Gateway, and
Envoy proxy support this feature and
use it for large scale production services. HttpRule defines the schema of
the gRPC/REST mapping. The mapping specifies how different portions of the
gRPC request message are mapped to the URL path, URL query parameters, and
HTTP request body. It also controls how the gRPC response message is mapped
to the HTTP response body. HttpRule is typically specified as an
google.api.http annotation on the gRPC method. Each mapping specifies a URL
path template and an HTTP method. The path template may refer to one or more
fields in the gRPC request message, as long as each field is a non-repeated
field with a primitive (non-message) type. The path template controls how
fields of the request message are mapped to the URL path. Example: service
Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option
(google.api.http) = { get: "/v1/{name=messages/}" }; } } message
GetMessageRequest { string name = 1; // Mapped to URL path. } message Message
{ string text = 1; // The resource content. } This enables an HTTP REST to
gRPC mapping as below: HTTP | gRPC -----|----- GET /v1/messages/123456 |
GetMessage(name: "messages/123456") Any fields in the request message which
are not bound by the path template automatically become HTTP query parameters
if there is no HTTP request body. For example: service Messaging { rpc
GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) =
{ get:"/v1/messages/{message_id}" }; } } message GetMessageRequest { message
SubMessage { string subfield = 1; } string message_id = 1; // Mapped to URL
path. int64 revision = 2; // Mapped to URL query parameter revision .
SubMessage sub = 3; // Mapped to URL query parameter sub.subfield . } This
enables a HTTP JSON to RPC mapping as below: HTTP | gRPC -----|----- GET /v1/messages/123456?revision=2&sub.subfield=foo | GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo")) Note that fields
which are mapped to URL query parameters must have a primitive type or a
repeated primitive type or a non-repeated message type. In the case of a
repeated type, the parameter can be repeated in the URL as
...?param=A¶m=B . In the case of a message type, each field of the
message is mapped to a separate parameter, such as
...?foo.a=A&foo.b=B&foo.c=C . For HTTP methods that allow a request body,
the body field specifies the mapping. Consider a REST update method on the
message resource collection: service Messaging { rpc
UpdateMessage(UpdateMessageRequest) returns (Message) { option
(google.api.http) = { patch: "/v1/messages/{message_id}" body: "message" }; }
} message UpdateMessageRequest { string message_id = 1; // mapped to the URL
Message message = 2; // mapped to the body } The following HTTP JSON to RPC
mapping is enabled, where the representation of the JSON in the request body
is determined by protos JSON encoding: HTTP | gRPC -----|----- PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: "123456" message { text: "Hi!" }) The special name * can be used in the body
mapping to define that every field not bound by the path template should be
mapped to the request body. This enables the following alternative definition
of the update method: service Messaging { rpc UpdateMessage(Message) returns
(Message) { option (google.api.http) = { patch: "/v1/messages/{message_id}"
body: "" }; } } message Message { string message_id = 1; string text = 2; }
The following HTTP JSON to RPC mapping is enabled: HTTP | gRPC -----|-----
PATCH /v1/messages/123456 { "text": "Hi!" } | UpdateMessage(message_id: "123456" text: "Hi!") Note that when using * in the body mapping, it is
not possible to have HTTP parameters, as all fields not bound by the path end
in the body. This makes this option more rarely used in practice when
defining REST APIs. The common usage of * is in custom methods which don't
use the URL at all for transferring data. It is possible to define multiple
HTTP methods for one RPC by using the additional_bindings option. Example:
service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) {
option (google.api.http) = { get: "/v1/messages/{message_id}"
additional_bindings { get: "/v1/users/{user_id}/messages/{message_id}" } }; }
} message GetMessageRequest { string message_id = 1; string user_id = 2; }
This enables the following two alternative HTTP JSON to RPC mappings: HTTP |
gRPC -----|----- GET /v1/messages/123456 | GetMessage(message_id: "123456") GET /v1/users/me/messages/123456 | GetMessage(user_id: "me" message_id: "123456") ## Rules for HTTP mapping 1. Leaf request fields
(recursive expansion nested messages in the request message) are classified
into three categories: - Fields referred by the path template. They are
passed via the URL path. - Fields referred by the HttpRule.body. They are
passed via the HTTP request body. - All other fields are passed via the URL
query parameters, and the parameter name is the field path in the request
message. A repeated field can be represented as multiple query parameters
under the same name. 2. If HttpRule.body is "", there is no URL query
parameter, all fields are passed via URL path and HTTP request body. 3. If
HttpRule.body is omitted, there is no HTTP request body, all fields are
passed via URL path and URL query parameters. ### Path template syntax
Template = "/" Segments [ Verb ] ; Segments = Segment { "/" Segment } ;
Segment = "" | "**" | LITERAL | Variable ; Variable = "{" FieldPath [ "="
Segments ] "}" ; FieldPath = IDENT { "." IDENT } ; Verb = ":" LITERAL ; The
syntax * matches a single URL path segment. The 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.
|
JavaSettings | Settings for Java client libraries.
|
JwtLocation | Specifies a location to extract JWT from an API request.
|
LabelDescriptor | A description of a label.
|
ListOperationsResponse | The response message for Operations.ListOperations.
|
ListServiceConfigsResponse | Response message for ListServiceConfigs method.
|
ListServiceRolloutsResponse | Response message for ListServiceRollouts method.
|
ListServicesResponse | Response message for ListServices method.
|
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
|
LoggingDestination | Configuration of a specific logging destination (the producer project or the
consumer project).
|
LongRunning | Describes settings to use when generating API methods that use the
long-running operation pattern. All default values below are from those used
in the client library generators (e.g.
Java).
|
ManagedService | The full representation of a Service that is managed by Google Service
Management.
|
Method | Method represents a method of an API interface.
|
MethodPolicy | Defines policies applying to an RPC method.
|
MethodSettings | Describes the generator configuration for a method.
|
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.
|
MetricDescriptorMetadata | Additional annotations that can be used to guide the usage of a metric.
|
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.
|
Mixin | Declares an API Interface to be included in this interface. The including
interface must redeclare all the methods from the included interface, but
documentation and options are inherited as follows: - If after comment and
whitespace stripping, the documentation string of the redeclared method is
empty, it will be inherited from the original method. - Each annotation
belonging to the service config (http, visibility) which is not set in the
redeclared method will be inherited. - If an http annotation is inherited,
the path pattern will be modified as follows. Any version prefix will be
replaced by the version of the including interface plus the root path if
specified. Example of a simple mixin: package google.acl.v1; service
AccessControl { // Get the underlying ACL object. rpc GetAcl(GetAclRequest)
returns (Acl) { option (google.api.http).get = "/v1/{resource=**}:getAcl"; }
} package google.storage.v2; service Storage { // rpc GetAcl(GetAclRequest)
returns (Acl); // Get a data record. rpc GetData(GetDataRequest) returns
(Data) { option (google.api.http).get = "/v2/{resource=**}"; } } Example of a
mixin configuration: apis: - name: google.storage.v2.Storage mixins: - name:
google.acl.v1.AccessControl The mixin construct implies that all methods in
AccessControl are also declared with same name and request/response types
in Storage . A documentation generator or annotation processor will see the
effective Storage.GetAcl method after inherting documentation and
annotations as follows: service Storage { // Get the underlying ACL object.
rpc GetAcl(GetAclRequest) returns (Acl) { option (google.api.http).get =
"/v2/{resource=**}:getAcl"; } ... } Note how the version in the path pattern
changed from v1 to v2 . If the root field in the mixin is specified, it
should be a relative path under which inherited HTTP paths are placed.
Example: apis: - name: google.storage.v2.Storage mixins: - name:
google.acl.v1.AccessControl root: acls This implies the following inherited
HTTP annotation: service Storage { // Get the underlying ACL object. rpc
GetAcl(GetAclRequest) returns (Acl) { option (google.api.http).get =
"/v2/acls/{resource=**}:getAcl"; } ... }
|
MonitoredResourceDescriptor | An object that describes the schema of a MonitoredResource object using a
type name and a set of labels. For example, the monitored resource descriptor
for Google Compute Engine VM instances has a type of "gce_instance" and
specifies the use of the labels "instance_id" and "zone" to identify
particular VM instances. Different APIs can support different monitored
resource types. APIs generally provide a list method that returns the
monitored resource descriptors used by the API.
|
Monitoring | Monitoring configuration of the service. The example below shows how to
configure monitored resources and metrics for monitoring. In the example, a
monitored resource and two metrics are defined. The
library.googleapis.com/book/returned_count metric is sent to both producer
and consumer projects, whereas the library.googleapis.com/book/num_overdue
metric is only sent to the consumer project. monitored_resources: - type:
library.googleapis.com/Branch display_name: "Library Branch" description: "A
branch of a library." launch_stage: GA labels: - key: resource_container
description: "The Cloud container (ie. project id) for the Branch." - key:
location description: "The location of the library branch." - key: branch_id
description: "The id of the branch." metrics: - name:
library.googleapis.com/book/returned_count display_name: "Books Returned"
description: "The count of books that have been returned." launch_stage: GA
metric_kind: DELTA value_type: INT64 unit: "1" labels: - key: customer_id
description: "The id of the customer." - name:
library.googleapis.com/book/num_overdue display_name: "Books Overdue"
description: "The current number of overdue books." launch_stage: GA
metric_kind: GAUGE value_type: INT64 unit: "1" labels: - key: customer_id
description: "The id of the customer." monitoring: producer_destinations: -
monitored_resource: library.googleapis.com/Branch metrics: -
library.googleapis.com/book/returned_count consumer_destinations: -
monitored_resource: library.googleapis.com/Branch metrics: -
library.googleapis.com/book/returned_count -
library.googleapis.com/book/num_overdue
|
MonitoringDestination | Configuration of a specific monitoring destination (the producer project or
the consumer project).
|
NodeSettings | Settings for Node client libraries.
|
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.
|
Operation | This resource represents a long-running operation that is the result of a
network API call.
|
OperationInfo | A message representing the message types used by a long-running operation.
Example: rpc Export(ExportRequest) returns (google.longrunning.Operation) {
option (google.longrunning.operation_info) = { response_type:
"ExportResponse" metadata_type: "ExportMetadata" }; }
|
OperationMetadata | The metadata associated with a long running operation resource.
|
OperationsListOptions | Additional options for ServiceManagement#operationsList.
|
Option | A protocol buffer option, which can be attached to a message, field,
enumeration, etc.
|
Page | Represents a documentation page. A page can contain subpages to represent
nested documentation set structure.
|
PhpSettings | Settings for Php client libraries.
|
Policy | An Identity and Access Management (IAM) policy, which specifies access
controls for Google Cloud resources. A Policy is a collection of
bindings . A binding binds one or more members , or principals, to a
single role . Principals can be user accounts, service accounts, Google
groups, and domains (such as G Suite). A role is a named list of
permissions; each role can be an IAM predefined role or a user-created
custom role. For some types of Google Cloud resources, a binding can also
specify a condition , which is a logical expression that allows access to a
resource only if the expression evaluates to true . A condition can add
constraints based on attributes of the request, the resource, or both. To
learn which resources support conditions in their IAM policies, see the IAM
documentation.
JSON example: { "bindings": [ { "role": "roles/resourcemanager.organizationAdmin", "members": [ "user:mike@example.com", "group:admins@example.com", "domain:google.com", "serviceAccount:my-project-id@appspot.gserviceaccount.com" ] }, { "role": "roles/resourcemanager.organizationViewer", "members": [ "user:eve@example.com" ], "condition": { "title": "expirable access", "description": "Does not grant access after Sep 2020", "expression": "request.time < timestamp('2020-10-01T00:00:00.000Z')", } } ], "etag": "BwWWja0YfJA=", "version": 3 } YAML example: ``` bindings: - members:
|
Publishing | This message configures the settings for publishing Google Cloud Client
libraries
generated from the service config.
|
PythonSettings | Settings for Python client libraries.
|
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 .
|
ResourceReference | Defines a proto annotation that describes a string field that refers to an
API resource.
|
Rollout | A rollout resource that defines how service configuration versions are
pushed to control plane systems. Typically, you create a new version of the
service config, and then create a Rollout to push the service config.
|
RubySettings | Settings for Ruby client libraries.
|
Service | Service is the root object of Google API service configuration (service
config). It describes the basic information about a logical service, such as
the service name and the user-facing 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. For more
information, see each proto message definition. Example: type:
google.api.Service name: calendar.googleapis.com title: Google Calendar API
apis: - name: google.calendar.v3.Calendar visibility: rules: - selector:
"google.calendar.v3." restriction: PREVIEW backend: rules: - selector:
"google.calendar.v3." address: calendar.example.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
|
ServicesConfigsGetOptions | Additional options for ServiceManagement#servicesConfigsGet.
|
ServicesConfigsListOptions | Additional options for ServiceManagement#servicesConfigsList.
|
ServicesGetConfigOptions | Additional options for ServiceManagement#servicesGetConfig.
|
ServicesListOptions | Additional options for ServiceManagement#servicesList.
|
ServicesRolloutsListOptions | Additional options for ServiceManagement#servicesRolloutsList.
|
SetIamPolicyRequest | Request message for SetIamPolicy method.
|
SourceContext | SourceContext represents information about the source of a protobuf
element, like the file in which it is defined.
|
SourceInfo | Source information used to create a Service Config
|
Status | The Status type defines a logical error model that is suitable for
different programming environments, including REST APIs and RPC APIs. It is
used by gRPC. Each Status message contains three
pieces of data: error code, error message, and error details. You can find
out more about this error model and how to work with it in the API Design
Guide.
|
Step | Represents the status of one operation step.
|
SubmitConfigSourceRequest | Request message for SubmitConfigSource method.
|
SubmitConfigSourceResponse | Response message for SubmitConfigSource method.
|
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.
|
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.
|
TestIamPermissionsRequest | Request message for TestIamPermissions method.
|
TestIamPermissionsResponse | Response message for TestIamPermissions method.
|
TrafficPercentStrategy | Strategy that specifies how clients of Google Service Controller want to
send traffic to use different config versions. This is generally used by API
proxy to split traffic based on your configured percentage for each config
version. One example of how to gradually rollout a new service configuration
using this strategy: Day 1 Rollout { id:
"example.googleapis.com/rollout_20160206" traffic_percent_strategy {
percentages: { "example.googleapis.com/20160201": 70.00
"example.googleapis.com/20160206": 30.00 } } } Day 2 Rollout { id:
"example.googleapis.com/rollout_20160207" traffic_percent_strategy: {
percentages: { "example.googleapis.com/20160206": 100.00 } } }
|
Type | A protocol buffer message type.
|
UndeleteServiceResponse | Response message for UndeleteService method.
|
Usage | Configuration controlling usage of a service.
|
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
|