googleapis.servicemanagement.v1 library


Generated advice about this change, used for providing more information about how a change will affect the existing service.
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 for detailed terminology.
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": "" }, { "log_type": "DATA_WRITE" }, { "log_type": "ADMIN_READ" } ] }, { "service": "", "audit_log_configs": [ { "log_type": "DATA_READ" }, { "log_type": "DATA_WRITE", "exempted_members": "" } ] } ] } For sampleservice, this policy enables DATA_READ, DATA_WRITE and ADMIN_READ logging. It also exempts from DATA_READ logging, and from DATA_WRITE logging.
Provides the configuration for logging a type of permissions. Example: { "audit_log_configs": [ { "log_type": "DATA_READ", "exempted_members": "" }, { "log_type": "DATA_WRITE" } ] } This enables 'DATA_READ' and 'DATA_WRITE' logging, while exempting from DATA_READ logging.
Authentication defines the authentication configuration for an API. Example for an API targeted for external use: name: authentication: providers: - id: google_calendar_auth jwks_uri: issuer: rules: - selector: "*" requirements: provider_id: google_calendar_auth
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.
Configuration for an authentication provider, including support for JSON Web Token (JWT).
User-defined authentication requirements, including support for JSON Web Token (JWT).
Backend defines the backend configuration for a service.
A backend rule provides configuration for an individual API element.
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 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: labels: - key: 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: [...]
Configuration of a specific billing destination (Currently only support bill against consumer project).
Associates members with a role.
Change report associated with a particular service configuration. It contains a list of ConfigChanges based on the comparison between two service configurations.
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.
Generic specification of a source configuration file
Represents a service configuration with its name and id.
Represents a source file which is used to generate the service configuration defined by google.api.Service.
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--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: - allowed_response_extensions: - You can also specify extension ID instead of fully qualified extension name here.
A context rule provides information about the context for an individual API element.
Selects and configures the service controller used by the service. The service controller handles features like abuse, quota, billing, logging, monitoring, etc.
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: - -
A custom error rule.
A custom pattern is used for defining custom HTTP verb.
Strategy used to delete a service. This strategy is a placeholder only used by the system generated rollout to delete a service.
Represents a diagnostic message (error or warning)
Operation payload for DisableService method.
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/ ==) - name: Tutorial content: (== include google/foo/ ==) subpages; - name: Java content: (== include google/foo/ ==) 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: To override the display text used for the link, this can be used: 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.
A documentation rule provides information about individual API elements.
Request message for EnableService method.
Operation payload for EnableService method.
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: endpoints: # Below entry makes 'google.example.library.v1.Library' # API be served from endpoint address # 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: allow_cors: true
Enum type definition.
Enum value definition.
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 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 ==" 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.
A single field of a message type.
Encapsulation of flow-specific error details for debugging. Used as a details field on an error Status, not intended for external use.
Request message for GenerateConfigReport method.
Response message for GenerateConfigReport method.
Request message for GetIamPolicy method.
Encapsulates settings provided to GetIamPolicy.
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.
gRPC Transcoding gRPC Transcoding is a feature for mapping between a gRPC [...]
Specifies a location to extract JWT from an API request.
A description of a label.
The response message for Operations.ListOperations.
Response message for ListServiceConfigs method.
Response message for ListServiceRollouts method.
Response message for ListServices method.
A description of a log type. Example in YAML format: - name: description: The history of borrowing and returning library items. display_name: Activity labels: - key: /customer_id description: Identifier of a library customer
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: 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: logs: - activity_history - purchase_history consumer_destinations: - monitored_resource: logs: - activity_history
Configuration of a specific logging destination (the producer project or the consumer project).
The full representation of a Service that is managed by Google Service Management.
Method represents a method of an API interface.
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.
Additional annotations that can be used to guide the usage of a metric.
Bind API methods to metrics. Binding a method to a metric causes that metric's configured quota behaviors to apply to the method call.
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; 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: 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 inheriting 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: 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"; } ... }
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 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 metric is sent to both producer and consumer projects, whereas the metric is only sent to the consumer project. monitored_resources: - type: 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: 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: 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: metrics: - consumer_destinations: - monitored_resource: metrics: - -
Configuration of a specific monitoring destination (the producer project or the consumer project).
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.
This resource represents a long-running operation that is the result of a network API call.
The metadata associated with a long running operation resource.
A protocol buffer option, which can be attached to a message, field, enumeration, etc.
Represents a documentation page. A page can contain subpages to represent nested documentation set structure.
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 to a single role. Members 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": "", "", "", "" }, { "role": "roles/resourcemanager.organizationViewer", "members": "" , "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: - - - - role: roles/resourcemanager.organizationAdmin - members: - role: roles/resourcemanager.organizationViewer 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 For a description of IAM and its features, see the IAM documentation.
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: 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: 1 - selector: google.example.library.v1.LibraryService.UpdateBook metric_costs: 2 - selector: google.example.library.v1.LibraryService.DeleteBook metric_costs: 1 Corresponding Metric definition: metrics: - name: display_name: Read requests metric_kind: DELTA value_type: INT64 - name: display_name: Write requests metric_kind: DELTA value_type: INT64
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.
Defines a proto annotation that describes a string field that refers to an API resource.
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.
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: title: Google Calendar API apis: - name: google.calendar.v3.Calendar authentication: providers: - id: google_calendar_auth jwks_uri: issuer: rules: - selector: "*" requirements: provider_id: google_calendar_auth
The per-product per-project service identity for a service. Use this field to configure per-product per-project service identity. Example of a service identity configuration. usage: service_identity: - service_account_parent: "projects/123456789" display_name: "Cloud XXX Service Agent" description: "Used as the identity of Cloud XXX to access resources"
Google Service Management allows service producers to publish their services on Google Cloud Platform so that they can be discovered and used by service consumers.
Request message for SetIamPolicy method.
SourceContext represents information about the source of a protobuf element, like the file in which it is defined.
Source information used to create a Service Config
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.
Represents the status of one operation step.
Request message for SubmitConfigSource method.
Response message for SubmitConfigSource method.
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.
Define a system parameter rule mapping system parameter definitions to methods.
System parameter configuration A system parameter is a special kind of [...]
Request message for TestIamPermissions method.
Response message for TestIamPermissions method.
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: "" traffic_percent_strategy { percentages: { "": 70.00 "": 30.00 } } } Day 2 Rollout { id: "" traffic_percent_strategy: { percentages: { "": 100.00 } } }
A protocol buffer message type.
Response message for UndeleteService method.
Configuration controlling usage of a service.
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: [...]


USER_AGENT → const String
'dart-api-client servicemanagement/v1'

Exceptions / Errors

Represents a general error reported by the API endpoint.
Represents a specific error reported by the API endpoint.