google-apis-serviceusage_v1beta1 0.57.0 → 0.59.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: de479121e1a496c1721fd3e24bab3702c8f4a5b3ca69b8036cc8e68a20c60c83
4
- data.tar.gz: cd1c63a5e980c3712ad179e658f045bc2947ee65ce956652fc5b406edbcf084f
3
+ metadata.gz: d84c1d418a3052690fe4407dd850c37dbec266b1c428f10777ab7b5e5e592aa1
4
+ data.tar.gz: 7f0d66462839ba6477503bdba5fbd3ef75d5c6c3801dace0fc971ea17cedb8dd
5
5
  SHA512:
6
- metadata.gz: ba075022669530418bf188ab4fff48889422a647a04da99c886d47ae72e9c1112996d808295299b06d2d35b29f1ea452e2dbb87494a46f1210484dcd91c8e6a7
7
- data.tar.gz: 357b2c5d638016220b00660d73bac93fa9078efbe51014f362a81b608288c1c2a1a3a558f4c5e16b250f34b31077ac42d5e91128ea0f165a95d4dbe72e19488a
6
+ metadata.gz: 26bd3fd3164544da4aad664181f3ca75e8b2fb0e6b6579cf9ce5291cf79e78867709a225435f241549e7669e56b33edc7f1e3dd7172ad835313ae001eb569de9
7
+ data.tar.gz: 13fce8d2ef91c2b85e12886ef682f7de9a1b842fa359119ad906ba369a0c415d83d4bb9fb37e953779674d5440895f10fce3055ffe25332adfae52c7bbf69fcc
data/CHANGELOG.md CHANGED
@@ -1,5 +1,13 @@
1
1
  # Release history for google-apis-serviceusage_v1beta1
2
2
 
3
+ ### v0.59.0 (2024-07-25)
4
+
5
+ * Regenerated from discovery document revision 20240712
6
+
7
+ ### v0.58.0 (2024-06-16)
8
+
9
+ * Regenerated from discovery document revision 20240602
10
+
3
11
  ### v0.57.0 (2024-05-19)
4
12
 
5
13
  * Regenerated using generator version 0.15.0
@@ -1006,12 +1006,14 @@ module Google
1006
1006
  # @return [Array<String>]
1007
1007
  attr_accessor :allowed_response_extensions
1008
1008
 
1009
- # A list of full type names of provided contexts.
1009
+ # A list of full type names of provided contexts. It is used to support
1010
+ # propagating HTTP headers and ETags from the response extension.
1010
1011
  # Corresponds to the JSON property `provided`
1011
1012
  # @return [Array<String>]
1012
1013
  attr_accessor :provided
1013
1014
 
1014
- # A list of full type names of requested contexts.
1015
+ # A list of full type names of requested contexts, only the requested context
1016
+ # will be made available to the backend.
1015
1017
  # Corresponds to the JSON property `requested`
1016
1018
  # @return [Array<String>]
1017
1019
  attr_accessor :requested
@@ -2577,7 +2579,7 @@ module Google
2577
2579
  end
2578
2580
  end
2579
2581
 
2580
- # # gRPC Transcoding gRPC Transcoding is a feature for mapping between a gRPC
2582
+ # gRPC Transcoding gRPC Transcoding is a feature for mapping between a gRPC
2581
2583
  # method and one or more HTTP REST endpoints. It allows developers to build a
2582
2584
  # single API service that supports both gRPC APIs and REST APIs. Many systems,
2583
2585
  # including [Google APIs](https://github.com/googleapis/googleapis), [Cloud
@@ -2597,70 +2599,69 @@ module Google
2597
2599
  # Message) ` option (google.api.http) = ` get: "/v1/`name=messages/*`" `; ` `
2598
2600
  # message GetMessageRequest ` string name = 1; // Mapped to URL path. ` message
2599
2601
  # Message ` string text = 1; // The resource content. ` This enables an HTTP
2600
- # REST to gRPC mapping as below: HTTP | gRPC -----|----- `GET /v1/messages/
2601
- # 123456` | `GetMessage(name: "messages/123456")` Any fields in the request
2602
- # message which are not bound by the path template automatically become HTTP
2603
- # query parameters if there is no HTTP request body. For example: service
2604
- # Messaging ` rpc GetMessage(GetMessageRequest) returns (Message) ` option (
2605
- # google.api.http) = ` get:"/v1/messages/`message_id`" `; ` ` message
2606
- # GetMessageRequest ` message SubMessage ` string subfield = 1; ` string
2607
- # message_id = 1; // Mapped to URL path. int64 revision = 2; // Mapped to URL
2608
- # query parameter `revision`. SubMessage sub = 3; // Mapped to URL query
2609
- # parameter `sub.subfield`. ` This enables a HTTP JSON to RPC mapping as below:
2610
- # HTTP | gRPC -----|----- `GET /v1/messages/123456?revision=2&sub.subfield=foo` |
2611
- # `GetMessage(message_id: "123456" revision: 2 sub: SubMessage(subfield: "foo"))
2612
- # ` Note that fields which are mapped to URL query parameters must have a
2613
- # primitive type or a repeated primitive type or a non-repeated message type. In
2614
- # the case of a repeated type, the parameter can be repeated in the URL as `...?
2615
- # param=A&param=B`. In the case of a message type, each field of the message is
2616
- # mapped to a separate parameter, such as `...?foo.a=A&foo.b=B&foo.c=C`. For
2617
- # HTTP methods that allow a request body, the `body` field specifies the mapping.
2618
- # Consider a REST update method on the message resource collection: service
2619
- # Messaging ` rpc UpdateMessage(UpdateMessageRequest) returns (Message) ` option
2620
- # (google.api.http) = ` patch: "/v1/messages/`message_id`" body: "message" `; ` `
2621
- # message UpdateMessageRequest ` string message_id = 1; // mapped to the URL
2622
- # Message message = 2; // mapped to the body ` The following HTTP JSON to RPC
2623
- # mapping is enabled, where the representation of the JSON in the request body
2624
- # is determined by protos JSON encoding: HTTP | gRPC -----|----- `PATCH /v1/
2625
- # messages/123456 ` "text": "Hi!" `` | `UpdateMessage(message_id: "123456"
2626
- # message ` text: "Hi!" `)` The special name `*` can be used in the body mapping
2627
- # to define that every field not bound by the path template should be mapped to
2628
- # the request body. This enables the following alternative definition of the
2629
- # update method: service Messaging ` rpc UpdateMessage(Message) returns (Message)
2630
- # ` option (google.api.http) = ` patch: "/v1/messages/`message_id`" body: "*" `;
2631
- # ` ` message Message ` string message_id = 1; string text = 2; ` The following
2632
- # HTTP JSON to RPC mapping is enabled: HTTP | gRPC -----|----- `PATCH /v1/
2633
- # messages/123456 ` "text": "Hi!" `` | `UpdateMessage(message_id: "123456" text:
2634
- # "Hi!")` Note that when using `*` in the body mapping, it is not possible to
2635
- # have HTTP parameters, as all fields not bound by the path end in the body.
2636
- # This makes this option more rarely used in practice when defining REST APIs.
2637
- # The common usage of `*` is in custom methods which don't use the URL at all
2638
- # for transferring data. It is possible to define multiple HTTP methods for one
2639
- # RPC by using the `additional_bindings` option. Example: service Messaging `
2640
- # rpc GetMessage(GetMessageRequest) returns (Message) ` option (google.api.http)
2641
- # = ` get: "/v1/messages/`message_id`" additional_bindings ` get: "/v1/users/`
2642
- # user_id`/messages/`message_id`" ` `; ` ` message GetMessageRequest ` string
2643
- # message_id = 1; string user_id = 2; ` This enables the following two
2644
- # alternative HTTP JSON to RPC mappings: HTTP | gRPC -----|----- `GET /v1/
2645
- # messages/123456` | `GetMessage(message_id: "123456")` `GET /v1/users/me/
2646
- # messages/123456` | `GetMessage(user_id: "me" message_id: "123456")` ## Rules
2647
- # for HTTP mapping 1. Leaf request fields (recursive expansion nested messages
2648
- # in the request message) are classified into three categories: - Fields
2649
- # referred by the path template. They are passed via the URL path. - Fields
2650
- # referred by the HttpRule.body. They are passed via the HTTP request body. -
2651
- # All other fields are passed via the URL query parameters, and the parameter
2652
- # name is the field path in the request message. A repeated field can be
2653
- # represented as multiple query parameters under the same name. 2. If HttpRule.
2654
- # body is "*", there is no URL query parameter, all fields are passed via URL
2655
- # path and HTTP request body. 3. If HttpRule.body is omitted, there is no HTTP
2656
- # request body, all fields are passed via URL path and URL query parameters. ###
2657
- # Path template syntax Template = "/" Segments [ Verb ] ; Segments = Segment ` "/
2658
- # " Segment ` ; Segment = "*" | "**" | LITERAL | Variable ; Variable = "`"
2659
- # FieldPath [ "=" Segments ] "`" ; FieldPath = IDENT ` "." IDENT ` ; Verb = ":"
2660
- # LITERAL ; The syntax `*` matches a single URL path segment. The syntax `**`
2661
- # matches zero or more URL path segments, which must be the last part of the URL
2662
- # path except the `Verb`. The syntax `Variable` matches part of the URL path as
2663
- # specified by its template. A variable template must not contain other
2602
+ # REST to gRPC mapping as below: - HTTP: `GET /v1/messages/123456` - gRPC: `
2603
+ # GetMessage(name: "messages/123456")` Any fields in the request message which
2604
+ # are not bound by the path template automatically become HTTP query parameters
2605
+ # if there is no HTTP request body. For example: service Messaging ` rpc
2606
+ # GetMessage(GetMessageRequest) returns (Message) ` option (google.api.http) = `
2607
+ # get:"/v1/messages/`message_id`" `; ` ` message GetMessageRequest ` message
2608
+ # SubMessage ` string subfield = 1; ` string message_id = 1; // Mapped to URL
2609
+ # path. int64 revision = 2; // Mapped to URL query parameter `revision`.
2610
+ # SubMessage sub = 3; // Mapped to URL query parameter `sub.subfield`. ` This
2611
+ # enables a HTTP JSON to RPC mapping as below: - HTTP: `GET /v1/messages/123456?
2612
+ # revision=2&sub.subfield=foo` - gRPC: `GetMessage(message_id: "123456" revision:
2613
+ # 2 sub: SubMessage(subfield: "foo"))` Note that fields which are mapped to URL
2614
+ # query parameters must have a primitive type or a repeated primitive type or a
2615
+ # non-repeated message type. In the case of a repeated type, the parameter can
2616
+ # be repeated in the URL as `...?param=A&param=B`. In the case of a message type,
2617
+ # each field of the message is mapped to a separate parameter, such as `...?foo.
2618
+ # a=A&foo.b=B&foo.c=C`. For HTTP methods that allow a request body, the `body`
2619
+ # field specifies the mapping. Consider a REST update method on the message
2620
+ # resource collection: service Messaging ` rpc UpdateMessage(
2621
+ # UpdateMessageRequest) returns (Message) ` option (google.api.http) = ` patch: "
2622
+ # /v1/messages/`message_id`" body: "message" `; ` ` message UpdateMessageRequest
2623
+ # ` string message_id = 1; // mapped to the URL Message message = 2; // mapped
2624
+ # to the body ` The following HTTP JSON to RPC mapping is enabled, where the
2625
+ # representation of the JSON in the request body is determined by protos JSON
2626
+ # encoding: - HTTP: `PATCH /v1/messages/123456 ` "text": "Hi!" `` - gRPC: `
2627
+ # UpdateMessage(message_id: "123456" message ` text: "Hi!" `)` The special name `
2628
+ # *` can be used in the body mapping to define that every field not bound by the
2629
+ # path template should be mapped to the request body. This enables the following
2630
+ # alternative definition of the update method: service Messaging ` rpc
2631
+ # UpdateMessage(Message) returns (Message) ` option (google.api.http) = ` patch:
2632
+ # "/v1/messages/`message_id`" body: "*" `; ` ` message Message ` string
2633
+ # message_id = 1; string text = 2; ` The following HTTP JSON to RPC mapping is
2634
+ # enabled: - HTTP: `PATCH /v1/messages/123456 ` "text": "Hi!" `` - gRPC: `
2635
+ # UpdateMessage(message_id: "123456" text: "Hi!")` Note that when using `*` in
2636
+ # the body mapping, it is not possible to have HTTP parameters, as all fields
2637
+ # not bound by the path end in the body. This makes this option more rarely used
2638
+ # in practice when defining REST APIs. The common usage of `*` is in custom
2639
+ # methods which don't use the URL at all for transferring data. It is possible
2640
+ # to define multiple HTTP methods for one RPC by using the `additional_bindings`
2641
+ # option. Example: service Messaging ` rpc GetMessage(GetMessageRequest) returns
2642
+ # (Message) ` option (google.api.http) = ` get: "/v1/messages/`message_id`"
2643
+ # additional_bindings ` get: "/v1/users/`user_id`/messages/`message_id`" ` `; ` `
2644
+ # message GetMessageRequest ` string message_id = 1; string user_id = 2; ` This
2645
+ # enables the following two alternative HTTP JSON to RPC mappings: - HTTP: `GET /
2646
+ # v1/messages/123456` - gRPC: `GetMessage(message_id: "123456")` - HTTP: `GET /
2647
+ # v1/users/me/messages/123456` - gRPC: `GetMessage(user_id: "me" message_id: "
2648
+ # 123456")` Rules for HTTP mapping 1. Leaf request fields (recursive expansion
2649
+ # nested messages in the request message) are classified into three categories: -
2650
+ # Fields referred by the path template. They are passed via the URL path. -
2651
+ # Fields referred by the HttpRule.body. They are passed via the HTTP request
2652
+ # body. - All other fields are passed via the URL query parameters, and the
2653
+ # parameter name is the field path in the request message. A repeated field can
2654
+ # be represented as multiple query parameters under the same name. 2. If
2655
+ # HttpRule.body is "*", there is no URL query parameter, all fields are passed
2656
+ # via URL path and HTTP request body. 3. If HttpRule.body is omitted, there is
2657
+ # no HTTP request body, all fields are passed via URL path and URL query
2658
+ # parameters. Path template syntax Template = "/" Segments [ Verb ] ; Segments =
2659
+ # Segment ` "/" Segment ` ; Segment = "*" | "**" | LITERAL | Variable ; Variable
2660
+ # = "`" FieldPath [ "=" Segments ] "`" ; FieldPath = IDENT ` "." IDENT ` ; Verb =
2661
+ # ":" LITERAL ; The syntax `*` matches a single URL path segment. The syntax `**
2662
+ # ` matches zero or more URL path segments, which must be the last part of the
2663
+ # URL path except the `Verb`. The syntax `Variable` matches part of the URL path
2664
+ # as specified by its template. A variable template must not contain other
2664
2665
  # variables. If a variable matches a single path segment, its template may be
2665
2666
  # omitted, e.g. ``var`` is equivalent to ``var=*``. The syntax `LITERAL` matches
2666
2667
  # literal text in the URL path. If the `LITERAL` contains any reserved character,
@@ -2675,7 +2676,7 @@ module Google
2675
2676
  # except `[-_.~/0-9a-zA-Z]` are percent-encoded. The server side does the
2676
2677
  # reverse decoding, except "%2F" and "%2f" are left unchanged. Such variables
2677
2678
  # show up in the [Discovery Document](https://developers.google.com/discovery/v1/
2678
- # reference/apis) as ``+var``. ## Using gRPC API Service Configuration gRPC API
2679
+ # reference/apis) as ``+var``. Using gRPC API Service Configuration gRPC API
2679
2680
  # Service Configuration (service config) is a configuration language for
2680
2681
  # configuring a gRPC service to become a user-facing product. The service config
2681
2682
  # is simply the YAML representation of the `google.api.Service` proto message.
@@ -2685,27 +2686,27 @@ module Google
2685
2686
  # effect as the proto annotation. This can be particularly useful if you have a
2686
2687
  # proto that is reused in multiple services. Note that any transcoding specified
2687
2688
  # in the service config will override any matching transcoding configuration in
2688
- # the proto. Example: http: rules: # Selects a gRPC method and applies HttpRule
2689
- # to it. - selector: example.v1.Messaging.GetMessage get: /v1/messages/`
2690
- # message_id`/`sub.subfield` ## Special notes When gRPC Transcoding is used to
2691
- # map a gRPC to JSON REST endpoints, the proto to JSON conversion must follow
2692
- # the [proto3 specification](https://developers.google.com/protocol-buffers/docs/
2693
- # proto3#json). While the single segment variable follows the semantics of [RFC
2694
- # 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String
2695
- # Expansion, the multi segment variable **does not** follow RFC 6570 Section 3.2.
2696
- # 3 Reserved Expansion. The reason is that the Reserved Expansion does not
2697
- # expand special characters like `?` and `#`, which would lead to invalid URLs.
2698
- # As the result, gRPC Transcoding uses a custom encoding for multi segment
2699
- # variables. The path variables **must not** refer to any repeated or mapped
2700
- # field, because client libraries are not capable of handling such variable
2701
- # expansion. The path variables **must not** capture the leading "/" character.
2702
- # The reason is that the most common use case "`var`" does not capture the
2703
- # leading "/" character. For consistency, all path variables must share the same
2704
- # behavior. Repeated message fields must not be mapped to URL query parameters,
2705
- # because no client library can support such complicated mapping. If an API
2706
- # needs to use a JSON array for request or response body, it can map the request
2707
- # or response body to a repeated field. However, some gRPC Transcoding
2708
- # implementations may not support this feature.
2689
+ # the proto. The following example selects a gRPC method and applies an `
2690
+ # HttpRule` to it: http: rules: - selector: example.v1.Messaging.GetMessage get:
2691
+ # /v1/messages/`message_id`/`sub.subfield` Special notes When gRPC Transcoding
2692
+ # is used to map a gRPC to JSON REST endpoints, the proto to JSON conversion
2693
+ # must follow the [proto3 specification](https://developers.google.com/protocol-
2694
+ # buffers/docs/proto3#json). While the single segment variable follows the
2695
+ # semantics of [RFC 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2
2696
+ # Simple String Expansion, the multi segment variable **does not** follow RFC
2697
+ # 6570 Section 3.2.3 Reserved Expansion. The reason is that the Reserved
2698
+ # Expansion does not expand special characters like `?` and `#`, which would
2699
+ # lead to invalid URLs. As the result, gRPC Transcoding uses a custom encoding
2700
+ # for multi segment variables. The path variables **must not** refer to any
2701
+ # repeated or mapped field, because client libraries are not capable of handling
2702
+ # such variable expansion. The path variables **must not** capture the leading "/
2703
+ # " character. The reason is that the most common use case "`var`" does not
2704
+ # capture the leading "/" character. For consistency, all path variables must
2705
+ # share the same behavior. Repeated message fields must not be mapped to URL
2706
+ # query parameters, because no client library can support such complicated
2707
+ # mapping. If an API needs to use a JSON array for request or response body, it
2708
+ # can map the request or response body to a repeated field. However, some gRPC
2709
+ # Transcoding implementations may not support this feature.
2709
2710
  class HttpRule
2710
2711
  include Google::Apis::Core::Hashable
2711
2712
 
@@ -16,13 +16,13 @@ module Google
16
16
  module Apis
17
17
  module ServiceusageV1beta1
18
18
  # Version of the google-apis-serviceusage_v1beta1 gem
19
- GEM_VERSION = "0.57.0"
19
+ GEM_VERSION = "0.59.0"
20
20
 
21
21
  # Version of the code generator used to generate this client
22
22
  GENERATOR_VERSION = "0.15.0"
23
23
 
24
24
  # Revision of the discovery document this client was generated from
25
- REVISION = "20240429"
25
+ REVISION = "20240712"
26
26
  end
27
27
  end
28
28
  end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: google-apis-serviceusage_v1beta1
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.57.0
4
+ version: 0.59.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - Google LLC
8
8
  autorequire:
9
9
  bindir: bin
10
10
  cert_chain: []
11
- date: 2024-05-19 00:00:00.000000000 Z
11
+ date: 2024-07-25 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: google-apis-core
@@ -58,7 +58,7 @@ licenses:
58
58
  metadata:
59
59
  bug_tracker_uri: https://github.com/googleapis/google-api-ruby-client/issues
60
60
  changelog_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-serviceusage_v1beta1/CHANGELOG.md
61
- documentation_uri: https://googleapis.dev/ruby/google-apis-serviceusage_v1beta1/v0.57.0
61
+ documentation_uri: https://googleapis.dev/ruby/google-apis-serviceusage_v1beta1/v0.59.0
62
62
  source_code_uri: https://github.com/googleapis/google-api-ruby-client/tree/main/generated/google-apis-serviceusage_v1beta1
63
63
  post_install_message:
64
64
  rdoc_options: []