From af83fb6f94e3dddabfcdce2a8636b43054a844ed Mon Sep 17 00:00:00 2001 From: Google APIs Date: Sat, 8 Jun 2019 00:37:24 +0000 Subject: [PATCH] Autogenerated update (2019-06-08) Update: - dialogflow_v2 - dialogflow_v2beta1 - logging_v2 - vision_v1 - vision_v1p1beta1 - vision_v1p2beta1 --- generated/google/apis/dialogflow_v2.rb | 2 +- .../google/apis/dialogflow_v2/classes.rb | 123 +----- generated/google/apis/dialogflow_v2beta1.rb | 2 +- .../google/apis/dialogflow_v2beta1/classes.rb | 144 ++----- .../dialogflow_v2beta1/representations.rb | 1 + generated/google/apis/logging_v2.rb | 7 +- generated/google/apis/logging_v2/service.rb | 5 +- generated/google/apis/vision_v1.rb | 2 +- generated/google/apis/vision_v1/classes.rb | 369 ++---------------- generated/google/apis/vision_v1p1beta1.rb | 2 +- .../google/apis/vision_v1p1beta1/classes.rb | 328 ++-------------- generated/google/apis/vision_v1p2beta1.rb | 2 +- .../google/apis/vision_v1p2beta1/classes.rb | 328 ++-------------- 13 files changed, 154 insertions(+), 1161 deletions(-) diff --git a/generated/google/apis/dialogflow_v2.rb b/generated/google/apis/dialogflow_v2.rb index 66590a45a..11d55f82d 100644 --- a/generated/google/apis/dialogflow_v2.rb +++ b/generated/google/apis/dialogflow_v2.rb @@ -26,7 +26,7 @@ module Google # @see https://cloud.google.com/dialogflow-enterprise/ module DialogflowV2 VERSION = 'V2' - REVISION = '20190527' + REVISION = '20190601' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/dialogflow_v2/classes.rb b/generated/google/apis/dialogflow_v2/classes.rb index 452058172..0f64d9cec 100644 --- a/generated/google/apis/dialogflow_v2/classes.rb +++ b/generated/google/apis/dialogflow_v2/classes.rb @@ -511,43 +511,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `webhookStatus` # @return [Google::Apis::DialogflowV2::GoogleRpcStatus] attr_accessor :webhook_status @@ -4488,43 +4455,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::DialogflowV2::GoogleRpcStatus] attr_accessor :error @@ -4591,43 +4525,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). class GoogleRpcStatus include Google::Apis::Core::Hashable diff --git a/generated/google/apis/dialogflow_v2beta1.rb b/generated/google/apis/dialogflow_v2beta1.rb index 3e21c77f5..fcb308615 100644 --- a/generated/google/apis/dialogflow_v2beta1.rb +++ b/generated/google/apis/dialogflow_v2beta1.rb @@ -26,7 +26,7 @@ module Google # @see https://cloud.google.com/dialogflow-enterprise/ module DialogflowV2beta1 VERSION = 'V2beta1' - REVISION = '20190520' + REVISION = '20190601' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/dialogflow_v2beta1/classes.rb b/generated/google/apis/dialogflow_v2beta1/classes.rb index b341f1a74..69ae23d8e 100644 --- a/generated/google/apis/dialogflow_v2beta1/classes.rb +++ b/generated/google/apis/dialogflow_v2beta1/classes.rb @@ -1992,7 +1992,7 @@ module Google # Represents the query input. It can contain either: # 1. An audio config which # instructs the speech recognizer how to process the speech audio. - # 2. A conversational query in the form of text,. + # 2. A conversational query in the form of text. # 3. An event that specifies which intent to trigger. # Corresponds to the JSON property `queryInput` # @return [Google::Apis::DialogflowV2beta1::GoogleCloudDialogflowV2beta1QueryInput] @@ -2061,43 +2061,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `webhookStatus` # @return [Google::Apis::DialogflowV2beta1::GoogleRpcStatus] attr_accessor :webhook_status @@ -2444,6 +2411,15 @@ module Google # @return [String] attr_accessor :audio_encoding + # Optional. If `true`, Dialogflow returns SpeechWordInfo in + # StreamingRecognitionResult with information about the recognized speech + # words, e.g. start and end time offsets. If false or unspecified, Speech + # doesn't return any word-level information. + # Corresponds to the JSON property `enableWordInfo` + # @return [Boolean] + attr_accessor :enable_word_info + alias_method :enable_word_info?, :enable_word_info + # Required. The language of the supplied audio. Dialogflow does not do # translations. See [Language # Support](https://cloud.google.com/dialogflow-enterprise/docs/reference/ @@ -2475,10 +2451,9 @@ module Google # @return [String] attr_accessor :model_variant - # Optional. The collection of phrase hints which are used to boost accuracy - # of speech recognition. - # Refer to - # [Cloud Speech API + # Optional. A list of strings containing words and phrases that the speech + # recognizer should recognize with higher likelihood. + # See [the Cloud Speech # documentation](https://cloud.google.com/speech-to-text/docs/basics#phrase- # hints) # for more details. @@ -2502,6 +2477,7 @@ module Google # Update properties of this object def update!(**args) @audio_encoding = args[:audio_encoding] if args.key?(:audio_encoding) + @enable_word_info = args[:enable_word_info] if args.key?(:enable_word_info) @language_code = args[:language_code] if args.key?(:language_code) @model = args[:model] if args.key?(:model) @model_variant = args[:model_variant] if args.key?(:model_variant) @@ -3964,7 +3940,7 @@ module Google # Represents the query input. It can contain either: # 1. An audio config which # instructs the speech recognizer how to process the speech audio. - # 2. A conversational query in the form of text,. + # 2. A conversational query in the form of text. # 3. An event that specifies which intent to trigger. class GoogleCloudDialogflowV2beta1QueryInput include Google::Apis::Core::Hashable @@ -4698,43 +4674,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::DialogflowV2beta1::GoogleRpcStatus] attr_accessor :error @@ -4801,43 +4744,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). class GoogleRpcStatus include Google::Apis::Core::Hashable diff --git a/generated/google/apis/dialogflow_v2beta1/representations.rb b/generated/google/apis/dialogflow_v2beta1/representations.rb index bac0320a0..9d7e69ac3 100644 --- a/generated/google/apis/dialogflow_v2beta1/representations.rb +++ b/generated/google/apis/dialogflow_v2beta1/representations.rb @@ -1347,6 +1347,7 @@ module Google # @private class Representation < Google::Apis::Core::JsonRepresentation property :audio_encoding, as: 'audioEncoding' + property :enable_word_info, as: 'enableWordInfo' property :language_code, as: 'languageCode' property :model, as: 'model' property :model_variant, as: 'modelVariant' diff --git a/generated/google/apis/logging_v2.rb b/generated/google/apis/logging_v2.rb index dcf022203..85213e52c 100644 --- a/generated/google/apis/logging_v2.rb +++ b/generated/google/apis/logging_v2.rb @@ -20,12 +20,15 @@ module Google module Apis # Stackdriver Logging API # - # Writes log entries and manages your Logging configuration. + # Writes log entries and manages your Stackdriver Logging configuration. The + # table entries below are presented in alphabetical order, not in order of + # common use. For explanations of the concepts found in the table entries, read + # the Stackdriver Logging documentation. # # @see https://cloud.google.com/logging/docs/ module LoggingV2 VERSION = 'V2' - REVISION = '20190525' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/logging_v2/service.rb b/generated/google/apis/logging_v2/service.rb index 4134322ee..28a3aebf2 100644 --- a/generated/google/apis/logging_v2/service.rb +++ b/generated/google/apis/logging_v2/service.rb @@ -22,7 +22,10 @@ module Google module LoggingV2 # Stackdriver Logging API # - # Writes log entries and manages your Logging configuration. + # Writes log entries and manages your Stackdriver Logging configuration. The + # table entries below are presented in alphabetical order, not in order of + # common use. For explanations of the concepts found in the table entries, read + # the Stackdriver Logging documentation. # # @example # require 'google/apis/logging_v2' diff --git a/generated/google/apis/vision_v1.rb b/generated/google/apis/vision_v1.rb index 7046a44e1..e15233ae8 100644 --- a/generated/google/apis/vision_v1.rb +++ b/generated/google/apis/vision_v1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/vision/ module VisionV1 VERSION = 'V1' - REVISION = '20190527' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/vision_v1/classes.rb b/generated/google/apis/vision_v1/classes.rb index 9af52269b..abe3ed702 100644 --- a/generated/google/apis/vision_v1/classes.rb +++ b/generated/google/apis/vision_v1/classes.rb @@ -170,43 +170,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -1411,43 +1378,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -3188,43 +3122,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -4965,43 +4866,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -6852,43 +6720,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -8778,43 +8613,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -11558,43 +11360,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1::Status] attr_accessor :error @@ -11978,43 +11747,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `indexError` # @return [Google::Apis::VisionV1::Status] attr_accessor :index_error @@ -12232,43 +11968,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/vision_v1p1beta1.rb b/generated/google/apis/vision_v1p1beta1.rb index b8d7731af..17a1bf55e 100644 --- a/generated/google/apis/vision_v1p1beta1.rb +++ b/generated/google/apis/vision_v1p1beta1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/vision/ module VisionV1p1beta1 VERSION = 'V1p1beta1' - REVISION = '20190527' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/vision_v1p1beta1/classes.rb b/generated/google/apis/vision_v1p1beta1/classes.rb index a0dc5b34b..0f5efe824 100644 --- a/generated/google/apis/vision_v1p1beta1/classes.rb +++ b/generated/google/apis/vision_v1p1beta1/classes.rb @@ -71,43 +71,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -1158,43 +1125,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -3379,43 +3313,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -5156,43 +5057,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -7043,43 +6911,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -8969,43 +8804,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -11357,43 +11159,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p1beta1::Status] attr_accessor :error @@ -11874,43 +11643,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/vision_v1p2beta1.rb b/generated/google/apis/vision_v1p2beta1.rb index 1ad184601..4ac7a167d 100644 --- a/generated/google/apis/vision_v1p2beta1.rb +++ b/generated/google/apis/vision_v1p2beta1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/vision/ module VisionV1p2beta1 VERSION = 'V1p2beta1' - REVISION = '20190527' + REVISION = '20190531' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/vision_v1p2beta1/classes.rb b/generated/google/apis/vision_v1p2beta1/classes.rb index 6671effd7..2861de156 100644 --- a/generated/google/apis/vision_v1p2beta1/classes.rb +++ b/generated/google/apis/vision_v1p2beta1/classes.rb @@ -71,43 +71,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -1080,43 +1047,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -2935,43 +2869,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -5156,43 +5057,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -7043,43 +6911,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -8969,43 +8804,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -11357,43 +11159,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::VisionV1p2beta1::Status] attr_accessor :error @@ -11874,43 +11643,10 @@ module Google # 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](https://github.com/grpc). The error model is designed to be: - # - Simple to use and understand for most users - # - Flexible enough to meet unexpected needs - # # Overview - # The `Status` message contains three pieces of data: error code, error - # message, and error details. The error code should be an enum value of - # google.rpc.Code, but it may accept additional error codes if needed. The - # error message should be a developer-facing English message that helps - # developers *understand* and *resolve* the error. If a localized user-facing - # error message is needed, put the localized message in the error details or - # localize it in the client. The optional error details may contain arbitrary - # information about the error. There is a predefined set of error detail types - # in the package `google.rpc` that can be used for common error conditions. - # # Language mapping - # The `Status` message is the logical representation of the error model, but it - # is not necessarily the actual wire format. When the `Status` message is - # exposed in different client libraries and different wire protocols, it can be - # mapped differently. For example, it will likely be mapped to some exceptions - # in Java, but more likely mapped to some error codes in C. - # # Other uses - # The error model and the `Status` message can be used in a variety of - # environments, either with or without APIs, to provide a - # consistent developer experience across different environments. - # Example uses of this error model include: - # - Partial errors. If a service needs to return partial errors to the client, - # it may embed the `Status` in the normal response to indicate the partial - # errors. - # - Workflow errors. A typical workflow has multiple steps. Each step may - # have a `Status` message for error reporting. - # - Batch operations. If a client uses batch request and batch response, the - # `Status` message should be used directly inside batch response, one for - # each error sub-response. - # - Asynchronous operations. If an API call embeds asynchronous operation - # results in its response, the status of those operations should be - # represented directly using the `Status` message. - # - Logging. If some API errors are stored in logs, the message `Status` could - # be used directly after any stripping needed for security/privacy reasons. + # used by [gRPC](https://github.com/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](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable