google-apis-serviceusage_v1beta1 0.57.0 → 0.58.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:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 5a8df6694d6f338ec9f63b8b495b1101eada91fbc58980fedf7e7f938c8ddd05
|
4
|
+
data.tar.gz: 63e87160adca76b771247ac62daa560a204810946558d01f9d169e0110158efb
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: '088b996b9ad245ca0c3367ee3641411e5b6c18e0e47ffb53496e83562f178d20db596f60f3969b71ec68f53bb0f856745ef9a44b57fb0253cc6a3c1abd4d8e68'
|
7
|
+
data.tar.gz: 9f0a53c19258af3996f9d57d6a391ef1265a3ef68955aa1f589aa439788e411cff1fcc4680689b7da0e0baa092bc026c32f84eea171268b050cd2b913e70fa68
|
data/CHANGELOG.md
CHANGED
@@ -2577,7 +2577,7 @@ module Google
|
|
2577
2577
|
end
|
2578
2578
|
end
|
2579
2579
|
|
2580
|
-
#
|
2580
|
+
# gRPC Transcoding gRPC Transcoding is a feature for mapping between a gRPC
|
2581
2581
|
# method and one or more HTTP REST endpoints. It allows developers to build a
|
2582
2582
|
# single API service that supports both gRPC APIs and REST APIs. Many systems,
|
2583
2583
|
# including [Google APIs](https://github.com/googleapis/googleapis), [Cloud
|
@@ -2597,70 +2597,69 @@ module Google
|
|
2597
2597
|
# Message) ` option (google.api.http) = ` get: "/v1/`name=messages/*`" `; ` `
|
2598
2598
|
# message GetMessageRequest ` string name = 1; // Mapped to URL path. ` message
|
2599
2599
|
# Message ` string text = 1; // The resource content. ` This enables an HTTP
|
2600
|
-
# REST to gRPC mapping as below: HTTP
|
2601
|
-
#
|
2602
|
-
#
|
2603
|
-
#
|
2604
|
-
#
|
2605
|
-
#
|
2606
|
-
#
|
2607
|
-
#
|
2608
|
-
#
|
2609
|
-
#
|
2610
|
-
#
|
2611
|
-
#
|
2612
|
-
#
|
2613
|
-
#
|
2614
|
-
#
|
2615
|
-
#
|
2616
|
-
#
|
2617
|
-
#
|
2618
|
-
#
|
2619
|
-
#
|
2620
|
-
#
|
2621
|
-
#
|
2622
|
-
#
|
2623
|
-
#
|
2624
|
-
#
|
2625
|
-
#
|
2626
|
-
#
|
2627
|
-
#
|
2628
|
-
#
|
2629
|
-
#
|
2630
|
-
#
|
2631
|
-
#
|
2632
|
-
#
|
2633
|
-
#
|
2634
|
-
#
|
2635
|
-
#
|
2636
|
-
#
|
2637
|
-
#
|
2638
|
-
#
|
2639
|
-
#
|
2640
|
-
#
|
2641
|
-
#
|
2642
|
-
#
|
2643
|
-
#
|
2644
|
-
#
|
2645
|
-
# messages/123456`
|
2646
|
-
#
|
2647
|
-
#
|
2648
|
-
#
|
2649
|
-
# referred by the
|
2650
|
-
#
|
2651
|
-
#
|
2652
|
-
#
|
2653
|
-
#
|
2654
|
-
#
|
2655
|
-
#
|
2656
|
-
#
|
2657
|
-
#
|
2658
|
-
# "
|
2659
|
-
#
|
2660
|
-
#
|
2661
|
-
#
|
2662
|
-
#
|
2663
|
-
# specified by its template. A variable template must not contain other
|
2600
|
+
# REST to gRPC mapping as below: - HTTP: `GET /v1/messages/123456` - gRPC: `
|
2601
|
+
# GetMessage(name: "messages/123456")` Any fields in the request message which
|
2602
|
+
# are not bound by the path template automatically become HTTP query parameters
|
2603
|
+
# if there is no HTTP request body. For example: service Messaging ` rpc
|
2604
|
+
# GetMessage(GetMessageRequest) returns (Message) ` option (google.api.http) = `
|
2605
|
+
# get:"/v1/messages/`message_id`" `; ` ` message GetMessageRequest ` message
|
2606
|
+
# SubMessage ` string subfield = 1; ` string message_id = 1; // Mapped to URL
|
2607
|
+
# path. int64 revision = 2; // Mapped to URL query parameter `revision`.
|
2608
|
+
# SubMessage sub = 3; // Mapped to URL query parameter `sub.subfield`. ` This
|
2609
|
+
# enables a HTTP JSON to RPC mapping as below: - HTTP: `GET /v1/messages/123456?
|
2610
|
+
# revision=2&sub.subfield=foo` - gRPC: `GetMessage(message_id: "123456" revision:
|
2611
|
+
# 2 sub: SubMessage(subfield: "foo"))` Note that fields which are mapped to URL
|
2612
|
+
# query parameters must have a primitive type or a repeated primitive type or a
|
2613
|
+
# non-repeated message type. In the case of a repeated type, the parameter can
|
2614
|
+
# be repeated in the URL as `...?param=A¶m=B`. In the case of a message type,
|
2615
|
+
# each field of the message is mapped to a separate parameter, such as `...?foo.
|
2616
|
+
# a=A&foo.b=B&foo.c=C`. For HTTP methods that allow a request body, the `body`
|
2617
|
+
# field specifies the mapping. Consider a REST update method on the message
|
2618
|
+
# resource collection: service Messaging ` rpc UpdateMessage(
|
2619
|
+
# UpdateMessageRequest) returns (Message) ` option (google.api.http) = ` patch: "
|
2620
|
+
# /v1/messages/`message_id`" body: "message" `; ` ` message UpdateMessageRequest
|
2621
|
+
# ` string message_id = 1; // mapped to the URL Message message = 2; // mapped
|
2622
|
+
# to the body ` The following HTTP JSON to RPC mapping is enabled, where the
|
2623
|
+
# representation of the JSON in the request body is determined by protos JSON
|
2624
|
+
# encoding: - HTTP: `PATCH /v1/messages/123456 ` "text": "Hi!" `` - gRPC: `
|
2625
|
+
# UpdateMessage(message_id: "123456" message ` text: "Hi!" `)` The special name `
|
2626
|
+
# *` can be used in the body mapping to define that every field not bound by the
|
2627
|
+
# path template should be mapped to the request body. This enables the following
|
2628
|
+
# alternative definition of the update method: service Messaging ` rpc
|
2629
|
+
# UpdateMessage(Message) returns (Message) ` option (google.api.http) = ` patch:
|
2630
|
+
# "/v1/messages/`message_id`" body: "*" `; ` ` message Message ` string
|
2631
|
+
# message_id = 1; string text = 2; ` The following HTTP JSON to RPC mapping is
|
2632
|
+
# enabled: - HTTP: `PATCH /v1/messages/123456 ` "text": "Hi!" `` - gRPC: `
|
2633
|
+
# UpdateMessage(message_id: "123456" text: "Hi!")` Note that when using `*` in
|
2634
|
+
# the body mapping, it is not possible to have HTTP parameters, as all fields
|
2635
|
+
# not bound by the path end in the body. This makes this option more rarely used
|
2636
|
+
# in practice when defining REST APIs. The common usage of `*` is in custom
|
2637
|
+
# methods which don't use the URL at all for transferring data. It is possible
|
2638
|
+
# to define multiple HTTP methods for one RPC by using the `additional_bindings`
|
2639
|
+
# option. Example: service Messaging ` rpc GetMessage(GetMessageRequest) returns
|
2640
|
+
# (Message) ` option (google.api.http) = ` get: "/v1/messages/`message_id`"
|
2641
|
+
# additional_bindings ` get: "/v1/users/`user_id`/messages/`message_id`" ` `; ` `
|
2642
|
+
# message GetMessageRequest ` string message_id = 1; string user_id = 2; ` This
|
2643
|
+
# enables the following two alternative HTTP JSON to RPC mappings: - HTTP: `GET /
|
2644
|
+
# v1/messages/123456` - gRPC: `GetMessage(message_id: "123456")` - HTTP: `GET /
|
2645
|
+
# v1/users/me/messages/123456` - gRPC: `GetMessage(user_id: "me" message_id: "
|
2646
|
+
# 123456")` Rules for HTTP mapping 1. Leaf request fields (recursive expansion
|
2647
|
+
# nested messages in the request message) are classified into three categories: -
|
2648
|
+
# Fields referred by the path template. They are passed via the URL path. -
|
2649
|
+
# Fields referred by the HttpRule.body. They are passed via the HTTP request
|
2650
|
+
# body. - All other fields are passed via the URL query parameters, and the
|
2651
|
+
# parameter name is the field path in the request message. A repeated field can
|
2652
|
+
# be represented as multiple query parameters under the same name. 2. If
|
2653
|
+
# HttpRule.body is "*", there is no URL query parameter, all fields are passed
|
2654
|
+
# via URL path and HTTP request body. 3. If HttpRule.body is omitted, there is
|
2655
|
+
# no HTTP request body, all fields are passed via URL path and URL query
|
2656
|
+
# parameters. Path template syntax Template = "/" Segments [ Verb ] ; Segments =
|
2657
|
+
# Segment ` "/" Segment ` ; Segment = "*" | "**" | LITERAL | Variable ; Variable
|
2658
|
+
# = "`" FieldPath [ "=" Segments ] "`" ; FieldPath = IDENT ` "." IDENT ` ; Verb =
|
2659
|
+
# ":" LITERAL ; The syntax `*` matches a single URL path segment. The syntax `**
|
2660
|
+
# ` matches zero or more URL path segments, which must be the last part of the
|
2661
|
+
# URL path except the `Verb`. The syntax `Variable` matches part of the URL path
|
2662
|
+
# as specified by its template. A variable template must not contain other
|
2664
2663
|
# variables. If a variable matches a single path segment, its template may be
|
2665
2664
|
# omitted, e.g. ``var`` is equivalent to ``var=*``. The syntax `LITERAL` matches
|
2666
2665
|
# literal text in the URL path. If the `LITERAL` contains any reserved character,
|
@@ -2675,7 +2674,7 @@ module Google
|
|
2675
2674
|
# except `[-_.~/0-9a-zA-Z]` are percent-encoded. The server side does the
|
2676
2675
|
# reverse decoding, except "%2F" and "%2f" are left unchanged. Such variables
|
2677
2676
|
# show up in the [Discovery Document](https://developers.google.com/discovery/v1/
|
2678
|
-
# reference/apis) as ``+var``.
|
2677
|
+
# reference/apis) as ``+var``. Using gRPC API Service Configuration gRPC API
|
2679
2678
|
# Service Configuration (service config) is a configuration language for
|
2680
2679
|
# configuring a gRPC service to become a user-facing product. The service config
|
2681
2680
|
# is simply the YAML representation of the `google.api.Service` proto message.
|
@@ -2685,11 +2684,11 @@ module Google
|
|
2685
2684
|
# effect as the proto annotation. This can be particularly useful if you have a
|
2686
2685
|
# proto that is reused in multiple services. Note that any transcoding specified
|
2687
2686
|
# in the service config will override any matching transcoding configuration in
|
2688
|
-
# the proto. Example
|
2689
|
-
#
|
2690
|
-
# message_id`/`sub.subfield`
|
2691
|
-
#
|
2692
|
-
#
|
2687
|
+
# the proto. Example below selects a gRPC method and applies HttpRule to it.
|
2688
|
+
# http: rules: - selector: example.v1.Messaging.GetMessage get: /v1/messages/`
|
2689
|
+
# message_id`/`sub.subfield` Special notes When gRPC Transcoding is used to map
|
2690
|
+
# a gRPC to JSON REST endpoints, the proto to JSON conversion must follow the [
|
2691
|
+
# proto3 specification](https://developers.google.com/protocol-buffers/docs/
|
2693
2692
|
# proto3#json). While the single segment variable follows the semantics of [RFC
|
2694
2693
|
# 6570](https://tools.ietf.org/html/rfc6570) Section 3.2.2 Simple String
|
2695
2694
|
# Expansion, the multi segment variable **does not** follow RFC 6570 Section 3.2.
|
@@ -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.
|
19
|
+
GEM_VERSION = "0.58.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 = "
|
25
|
+
REVISION = "20240602"
|
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.
|
4
|
+
version: 0.58.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-
|
11
|
+
date: 2024-06-16 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.
|
61
|
+
documentation_uri: https://googleapis.dev/ruby/google-apis-serviceusage_v1beta1/v0.58.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: []
|