Get desktop application:
View/edit binary Protocol Buffers messages
A custom pattern is used for defining custom HTTP verb.
Used in:
The name of this custom HTTP verb.
The path matched by this custom verb.
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.
Conventional default for enums. Do not use this.
Specifically denotes a field as optional. While all fields in protocol buffers are optional, this may be specified for emphasis if appropriate.
Denotes a field as required. This indicates that the field **must** be provided as part of the request, and failure to do so will cause an error (usually `INVALID_ARGUMENT`).
Denotes a field as output only. This indicates that the field is provided in responses, but including the field in a request does nothing (the server *must* ignore it and *must not* throw an error as a result of the field's presence).
Denotes a field as input only. This indicates that the field is provided in requests, and the corresponding field is not included in output.
Denotes a field as immutable. This indicates that the field may be set once in a request to create a resource, but may not be changed thereafter.
Denotes that a (repeated) field is an unordered list. This indicates that the service may provide the elements of the list in any arbitrary order, rather than the order the user originally provided. Additionally, the list's order may or may not be stable.
Denotes that this field returns a non-empty default value if not set. This indicates that if the user provides the empty value in a request, a non-empty value will be returned. The user will not be aware of what non-empty value to expect.
Denotes that the field in a resource (a message annotated with google.api.resource) is used in the resource name to uniquely identify the resource. For AIP-compliant APIs, this should only be applied to the `name` field on the resource. This behavior should not be applied to references to other resources within the message. The identifier field of resources often have different field behavior depending on the request it is embedded in (e.g. for Create methods name is optional and unused, while for Update methods it is required). Instead of method-specific annotations, only `IDENTIFIER` is required.
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.
A list of HTTP configuration rules that apply to individual API methods. **NOTE:** All service configuration rules follow "last one wins" order.
When set to true, URL path parmeters will be fully URI-decoded except in cases of single segment matches in reserved expansion, where "%2F" will be left encoded. The default behavior is to not decode RFC 6570 reserved characters in multi segment matches.
`HttpRule` defines the mapping of an RPC method to one or more HTTP REST API methods. The mapping specifies how different portions of the RPC request message are mapped to URL path, URL query parameters, and HTTP request body. The mapping is typically specified as an `google.api.http` annotation on the RPC method, see "google/api/annotations.proto" for details. The mapping consists of a field specifying the path template and method kind. The path template can refer to fields in the request message, as in the example below which describes a REST GET operation on a resource collection of messages: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http).get = "/v1/messages/{message_id}/{sub.subfield}"; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // mapped to the URL SubMessage sub = 2; // `sub.subfield` is url-mapped } message Message { string text = 1; // content of the resource } The same http annotation can alternatively be expressed inside the `GRPC API Configuration` YAML file. http: rules: - selector: <proto_package_name>.Messaging.GetMessage get: /v1/messages/{message_id}/{sub.subfield} This definition enables an automatic, bidrectional mapping of HTTP JSON to RPC. Example: HTTP | RPC -----|----- `GET /v1/messages/123456/foo` | `GetMessage(message_id: "123456" sub: SubMessage(subfield: "foo"))` In general, not only fields but also field paths can be referenced from a path pattern. Fields mapped to the path pattern cannot be repeated and must have a primitive (non-message) type. Any fields in the request message which are not bound by the path pattern automatically become (optional) HTTP query parameters. Assume the following definition of the request message: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http).get = "/v1/messages/{message_id}"; } } message GetMessageRequest { message SubMessage { string subfield = 1; } string message_id = 1; // mapped to the URL int64 revision = 2; // becomes a parameter SubMessage sub = 3; // `sub.subfield` becomes a parameter } This enables a HTTP JSON to RPC mapping as below: HTTP | RPC -----|----- `GET /v1/messages/123456?revision=2&sub.subfield=foo` | `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))` Note that fields which are mapped to HTTP parameters must have a primitive type or a repeated primitive type. Message types are not allowed. In the case of a repeated type, the parameter can be repeated in the URL, as in `...?param=A¶m=B`. For HTTP method kinds which allow a request body, the `body` field specifies the mapping. Consider a REST update method on the message resource collection: service Messaging { rpc UpdateMessage(UpdateMessageRequest) returns (Message) { option (google.api.http) = { put: "/v1/messages/{message_id}" body: "message" }; } } message UpdateMessageRequest { string message_id = 1; // mapped to the URL Message message = 2; // mapped to the body } The following HTTP JSON to RPC mapping is enabled, where the representation of the JSON in the request body is determined by protos JSON encoding: HTTP | RPC -----|----- `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" message { text: "Hi!" })` The special name `*` can be used in the body mapping to define that every field not bound by the path template should be mapped to the request body. This enables the following alternative definition of the update method: service Messaging { rpc UpdateMessage(Message) returns (Message) { option (google.api.http) = { put: "/v1/messages/{message_id}" body: "*" }; } } message Message { string message_id = 1; string text = 2; } The following HTTP JSON to RPC mapping is enabled: HTTP | RPC -----|----- `PUT /v1/messages/123456 { "text": "Hi!" }` | `UpdateMessage(message_id: "123456" text: "Hi!")` Note that when using `*` in the body mapping, it is not possible to have HTTP parameters, as all fields not bound by the path end in the body. This makes this option more rarely used in practice of defining REST APIs. The common usage of `*` is in custom methods which don't use the URL at all for transferring data. It is possible to define multiple HTTP methods for one RPC by using the `additional_bindings` option. Example: service Messaging { rpc GetMessage(GetMessageRequest) returns (Message) { option (google.api.http) = { get: "/v1/messages/{message_id}" additional_bindings { get: "/v1/users/{user_id}/messages/{message_id}" } }; } } message GetMessageRequest { string message_id = 1; string user_id = 2; } This enables the following two alternative HTTP JSON to RPC mappings: HTTP | RPC -----|----- `GET /v1/messages/123456` | `GetMessage(message_id: "123456")` `GET /v1/users/me/messages/123456` | `GetMessage(user_id: "me" message_id: "123456")` # Rules for HTTP mapping The rules for mapping HTTP path, query parameters, and body fields to the request message are as follows: 1. The `body` field specifies either `*` or a field path, or is omitted. If omitted, it indicates there is no HTTP request body. 2. Leaf fields (recursive expansion of nested messages in the request) can be classified into three types: (a) Matched in the URL template. (b) Covered by body (if body is `*`, everything except (a) fields; else everything under the body field) (c) All other fields. 3. URL query parameters found in the HTTP request are mapped to (c) fields. 4. Any body sent with an HTTP request can contain only (b) fields. The syntax of the path template is as follows: Template = "/" Segments [ Verb ] ; Segments = Segment { "/" Segment } ; Segment = "*" | "**" | LITERAL | Variable ; Variable = "{" FieldPath [ "=" Segments ] "}" ; FieldPath = IDENT { "." IDENT } ; Verb = ":" LITERAL ; The syntax `*` matches a single path segment. The syntax `**` matches zero or more path segments, which must be the last part of the path except the `Verb`. The syntax `LITERAL` matches literal text in the path. The syntax `Variable` matches part of the URL path as specified by its template. A variable template must not contain other variables. If a variable matches a single path segment, its template may be omitted, e.g. `{var}` is equivalent to `{var=*}`. If a variable contains exactly one path segment, such as `"{var}"` or `"{var=*}"`, when such a variable is expanded into a URL path, all characters except `[-_.~0-9a-zA-Z]` are percent-encoded. Such variables show up in the Discovery Document as `{var}`. If a variable contains one or more path segments, such as `"{var=foo/*}"` or `"{var=**}"`, when such a variable is expanded into a URL path, all characters except `[-_.~/0-9a-zA-Z]` are percent-encoded. Such variables show up in the Discovery Document as `{+var}`. NOTE: While the single segment variable matches the semantics of [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String Expansion, the multi segment variable **does not** match RFC 6570 Reserved Expansion. The reason is that the Reserved Expansion does not expand special characters like `?` and `#`, which would lead to invalid URLs. NOTE: the field paths in variables and in the `body` must not refer to repeated fields or map fields.
Used in:
Selects methods to which this rule applies. Refer to [selector][google.api.DocumentationRule.selector] for syntax details.
Determines the URL pattern is matched by this rules. This pattern can be used with any of the {get|put|post|delete|patch} methods. A custom method can be defined using the 'custom' field.
Used for listing and getting information about resources.
Used for updating a resource.
Used for creating a resource.
Used for deleting a resource.
Used for updating a resource.
The custom pattern is used for specifying an HTTP method that is not included in the `pattern` field, such as HEAD, or "*" to leave the HTTP method unspecified for this rule. The wild-card rule is useful for services that provide content to Web (HTML) clients.
The name of the request field whose value is mapped to the HTTP body, or `*` for mapping all fields not captured by the path pattern to the HTTP body. NOTE: the referred field must not be a repeated field and must be present at the top-level of request message type.
Additional HTTP bindings for the selector. Nested bindings must not contain an `additional_bindings` field themselves (that is, the nesting may only be one level deep).
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"
The resource type. It must be in the format of {service_name}/{resource_type_kind}. The `resource_type_kind` must be singular and must not include version numbers. Example: `storage.googleapis.com/Bucket` The value of the resource_type_kind must follow the regular expression /[A-Za-z][a-zA-Z0-9]+/. It should start with an upper case character and should use PascalCase (UpperCamelCase). The maximum number of characters allowed for the `resource_type_kind` is 100.
Optional. The relative resource name pattern associated with this resource type. The DNS prefix of the full resource name shouldn't be specified here. The path pattern must follow the syntax, which aligns with HTTP binding syntax: Template = Segment { "/" Segment } ; Segment = LITERAL | Variable ; Variable = "{" LITERAL "}" ; Examples: - "projects/{project}/topics/{topic}" - "projects/{project}/knowledgeBases/{knowledge_base}" The components in braces correspond to the IDs for each resource in the hierarchy. It is expected that, if multiple patterns are provided, the same component name (e.g. "project") refers to IDs of the same type of resource.
Optional. The field on the resource that designates the resource name field. If omitted, this is assumed to be "name".
Optional. The historical or future-looking state of the resource pattern. Example: // The InspectTemplate message originally only supported resource // names with organization, and project was added later. message InspectTemplate { option (google.api.resource) = { type: "dlp.googleapis.com/InspectTemplate" pattern: "organizations/{organization}/inspectTemplates/{inspect_template}" pattern: "projects/{project}/inspectTemplates/{inspect_template}" history: ORIGINALLY_SINGLE_PATTERN }; }
The plural name used in the resource name, such as 'projects' for the name of 'projects/{project}'. It is the same concept of the `plural` field in k8s CRD spec https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
The same concept of the `singular` field in k8s CRD spec https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/ Such as "project" for the `resourcemanager.googleapis.com/Project` type.
A description of the historical or future-looking state of the resource pattern.
Used in:
The "unset" value.
The resource originally had one pattern and launched as such, and additional patterns were added later.
The resource has one pattern, but the API owner expects to add more later. (This is the inverse of ORIGINALLY_SINGLE_PATTERN, and prevents that from being necessary once there are multiple patterns.)
Defines a proto annotation that describes a string field that refers to an API resource.
The resource type that the annotated field references. Example: message Subscription { string topic = 2 [(google.api.resource_reference) = { type: "pubsub.googleapis.com/Topic" }]; }
The resource type of a child collection that the annotated field references. This is useful for annotating the `parent` field that doesn't have a fixed resource type. Example: message ListLogEntriesRequest { string parent = 1 [(google.api.resource_reference) = { child_type: "logging.googleapis.com/LogEntry" }; }