classes.rb in google-api-client-0.29.0

- old
+ new

@@ -181,11 +181,11 @@
           @syntax = args[:syntax] if args.key?(:syntax)
           @version = args[:version] if args.key?(:version)
         end
       end
       
-      # Configuration for an anthentication provider, including support for
+      # Configuration for an authentication provider, including support for
       # [JSON Web Token
       # (JWT)](https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32).
       class AuthProvider
         include Google::Apis::Core::Hashable
       
@@ -1379,12 +1379,13 @@
       # 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"))`
+      # `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&param=B`. In the case of a message type, each field of the
       # message is mapped to a separate parameter, such as
@@ -1407,12 +1408,12 @@
       # 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!" `)`
+      # `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 `
@@ -1428,12 +1429,12 @@
       # 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!")`
+      # `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.
@@ -1455,12 +1456,12 @@
       # `
       # 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")`
+      # `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
@@ -1492,18 +1493,20 @@
       # 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](https://developers.google.com/discovery/v1/reference/apis)
-      # as ``var``.
+      # [Discovery
+      # Document](https://developers.google.com/discovery/v1/reference/apis) 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](https://developers.google.com/discovery/v1/reference/apis)
-      # as ``+var``.
+      # [Discovery
+      # Document](https://developers.google.com/discovery/v1/reference/apis) 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.