# Google Cloud RuntimeConfig API . projects . configs . waiters

## Instance Methods

Creates a Waiter resource. This operation returns a long-running Operation

Deletes the Waiter with the specified name.

Gets the Waiter resource with the specified name.

List Waiters within the given RuntimeConfig resource.

Retrieves the next page of results.

### Method Details

`create(parent=None, body, x__xgafv=None)`

    Creates a Waiter resource. This operation returns a long-running Operation
    resource which can be polled for completion. However, a Waiter with the
    given name will exist (and can be retrieved) prior to the resultant
    Operation completing. If the resultant Operation indicates a failure, the
    failed Waiter resource will still exist and must be deleted prior to
    subsequent creation attempts.

    Args:
      parent: string, The fully-qualified name of the configuration that will own the waiter.
    Required. Must be a valid configuration name. (required)
      body: object, The request body. (required)
        The object takes the form of:

    { # A Waiter resource waits for some condition within a RuntimeConfig resource
          # to be met. For example: each node in a distributed system startup process
          # writes a value to a Variable resource indicating its readiness. A Waiter
          # configured with the proper `success` condition can be used to wait until
          # some number of nodes have checked in.
          # Once created, a Waiter resource is immutable.
        "name": "A String", # Name of the variable resource.
            # It has format of
            # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",
            # Where `project_id` must be a valid Google Cloud project ID, `config_id`
            # must be a valid RuntimeConfig object and the `waiter_id` must match
            # RFC 1035 segment specification, and `len(waiter_id)` must be less than
            # 64 bytes.
            # The name is assigned by the client, but will be validated on the server
            # side to adhere to the format.
            # Name is immutable and cannot be changed. Required.
        "success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to
            # `true` and the `error` value will remain unset. The failure condition
            # takes precedence over the success condition. If both conditions are met, a
            # failure will be indicated. Required.
            # conditions may expand over time.
          "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
              # under the specified path prefix reaches the specified number.
              # For example, take the following variables in a RuntimeConfig object:
              #   /foo/variable1 = "value1"
              #   /foo/variable2 = "value2"
              #   /bar/variable3 = "value3"
              #
              # These variables would satisfy a Cardinality condition with `path` set to
              # "/foo" and `number` set to 2, but would not satisify the same condition
              # with `number` set to 3.
            "path": "A String", # The root of the variable subtree to monitor. Required.
            "number": 42, # The number of decendents of `path` that must exist before this condition
                # is met. Optional; defaults to 1 if not specified.
          },
        },
        "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to
            # `true` and the `error` code will be set to ABORTED. The failure condition
            # takes precedence over the success condition. If both conditions are met, a
            # failure will be indicated. This value is optional; if no failure condition
            # is set, the only failure scenario will be a timeout. Optional.
            # conditions may expand over time.
          "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
              # under the specified path prefix reaches the specified number.
              # For example, take the following variables in a RuntimeConfig object:
              #   /foo/variable1 = "value1"
              #   /foo/variable2 = "value2"
              #   /bar/variable3 = "value3"
              #
              # These variables would satisfy a Cardinality condition with `path` set to
              # "/foo" and `number` set to 2, but would not satisify the same condition
              # with `number` set to 3.
            "path": "A String", # The root of the variable subtree to monitor. Required.
            "number": 42, # The number of decendents of `path` that must exist before this condition
                # is met. Optional; defaults to 1 if not specified.
          },
        },
        "done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of
            # its conditions to be met.
            # If true, the Waiter has finished. If the Waiter finished due to a timeout
            # or failure, `error` will be set. Output only.
        "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If
            # this timeout elapses prior to the success or failure conditions being met,
            # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.
            # Required.
        "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.
            # Output only.
            # 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` which 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 purpose.
            #
            # - 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.
          "message": "A String", # A developer-facing error message, which should be in English. Any
              # user-facing error message should be localized and sent in the
              # google.rpc.Status.details field, or localized by the client.
          "code": 42, # The status code, which should be an enum value of google.rpc.Code.
          "details": [ # A list of messages that carry the error details.  There will be a
              # common set of message types for APIs to use.
            {
              "a_key": "", # Properties of the object. Contains field @ype with type URL.
            },
          ],
        },
        "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`
            # to this instant yields the timeout deadline for this Waiter. Output only.
      }

      x__xgafv: string, V1 error format.
        Allowed values
          1 - v1 error format
          2 - v2 error format

    Returns:
      An object of the form:

        { # This resource represents a long-running operation that is the result of a
          # network API call.
        "metadata": { # Service-specific metadata associated with the operation.  It typically
            # contains progress information and common metadata such as create time.
            # Some services might not provide such metadata.  Any method that returns a
            # long-running operation should document the metadata type, if any.
          "a_key": "", # Properties of the object. Contains field @ype with type URL.
        },
        "done": True or False, # If the value is `false`, it means the operation is still in progress.
            # If true, the operation is completed, and either `error` or `response` is
            # available.
        "response": { # The normal response of the operation in case of success.  If the original
            # method returns no data on success, such as `Delete`, the response is
            # `google.protobuf.Empty`.  If the original method is standard
            # `Get`/`Create`/`Update`, the response should be the resource.  For other
            # methods, the response should have the type `XxxResponse`, where `Xxx`
            # is the original method name.  For example, if the original method name
            # is `TakeSnapshot()`, the inferred response type is
            # `TakeSnapshotResponse`.
          "a_key": "", # Properties of the object. Contains field @ype with type URL.
        },
        "name": "A String", # The server-assigned name, which is only unique within the same service that
            # originally returns it. If you use the default HTTP mapping, the
            # `name` should have the format of `operations/some/unique/name`.
        "error": { # The `Status` type defines a logical error model that is suitable for different # The error result of the operation in case of failure.
            # 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` which 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 purpose.
            #
            # - 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.
          "message": "A String", # A developer-facing error message, which should be in English. Any
              # user-facing error message should be localized and sent in the
              # google.rpc.Status.details field, or localized by the client.
          "code": 42, # The status code, which should be an enum value of google.rpc.Code.
          "details": [ # A list of messages that carry the error details.  There will be a
              # common set of message types for APIs to use.
            {
              "a_key": "", # Properties of the object. Contains field @ype with type URL.
            },
          ],
        },
      }

`delete(name, x__xgafv=None)`

    Deletes the Waiter with the specified name.

    Args:
      name: string, The Waiter resource to delete. (required)
      x__xgafv: string, V1 error format.
        Allowed values
          1 - v1 error format
          2 - v2 error format

    Returns:
      An object of the form:

        { # A generic empty message that you can re-use to avoid defining duplicated
          # empty messages in your APIs. A typical example is to use it as the request
          # or the response type of an API method. For instance:
          #
          #     service Foo {
          #       rpc Bar(google.protobuf.Empty) returns (google.protobuf.Empty);
          #     }
          #
          # The JSON representation for `Empty` is empty JSON object `{}`.
      }

`get(name, x__xgafv=None)`

    Gets the Waiter resource with the specified name.

    Args:
      name: string, The fully-qualified name of the Waiter resource object to retrieve. (required)
      x__xgafv: string, V1 error format.
        Allowed values
          1 - v1 error format
          2 - v2 error format

    Returns:
      An object of the form:

        { # A Waiter resource waits for some condition within a RuntimeConfig resource
            # to be met. For example: each node in a distributed system startup process
            # writes a value to a Variable resource indicating its readiness. A Waiter
            # configured with the proper `success` condition can be used to wait until
            # some number of nodes have checked in.
            # Once created, a Waiter resource is immutable.
          "name": "A String", # Name of the variable resource.
              # It has format of
              # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",
              # Where `project_id` must be a valid Google Cloud project ID, `config_id`
              # must be a valid RuntimeConfig object and the `waiter_id` must match
              # RFC 1035 segment specification, and `len(waiter_id)` must be less than
              # 64 bytes.
              # The name is assigned by the client, but will be validated on the server
              # side to adhere to the format.
              # Name is immutable and cannot be changed. Required.
          "success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to
              # `true` and the `error` value will remain unset. The failure condition
              # takes precedence over the success condition. If both conditions are met, a
              # failure will be indicated. Required.
              # conditions may expand over time.
            "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
                # under the specified path prefix reaches the specified number.
                # For example, take the following variables in a RuntimeConfig object:
                #   /foo/variable1 = "value1"
                #   /foo/variable2 = "value2"
                #   /bar/variable3 = "value3"
                #
                # These variables would satisfy a Cardinality condition with `path` set to
                # "/foo" and `number` set to 2, but would not satisify the same condition
                # with `number` set to 3.
              "path": "A String", # The root of the variable subtree to monitor. Required.
              "number": 42, # The number of decendents of `path` that must exist before this condition
                  # is met. Optional; defaults to 1 if not specified.
            },
          },
          "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to
              # `true` and the `error` code will be set to ABORTED. The failure condition
              # takes precedence over the success condition. If both conditions are met, a
              # failure will be indicated. This value is optional; if no failure condition
              # is set, the only failure scenario will be a timeout. Optional.
              # conditions may expand over time.
            "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
                # under the specified path prefix reaches the specified number.
                # For example, take the following variables in a RuntimeConfig object:
                #   /foo/variable1 = "value1"
                #   /foo/variable2 = "value2"
                #   /bar/variable3 = "value3"
                #
                # These variables would satisfy a Cardinality condition with `path` set to
                # "/foo" and `number` set to 2, but would not satisify the same condition
                # with `number` set to 3.
              "path": "A String", # The root of the variable subtree to monitor. Required.
              "number": 42, # The number of decendents of `path` that must exist before this condition
                  # is met. Optional; defaults to 1 if not specified.
            },
          },
          "done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of
              # its conditions to be met.
              # If true, the Waiter has finished. If the Waiter finished due to a timeout
              # or failure, `error` will be set. Output only.
          "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If
              # this timeout elapses prior to the success or failure conditions being met,
              # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.
              # Required.
          "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.
              # Output only.
              # 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` which 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 purpose.
              #
              # - 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.
            "message": "A String", # A developer-facing error message, which should be in English. Any
                # user-facing error message should be localized and sent in the
                # google.rpc.Status.details field, or localized by the client.
            "code": 42, # The status code, which should be an enum value of google.rpc.Code.
            "details": [ # A list of messages that carry the error details.  There will be a
                # common set of message types for APIs to use.
              {
                "a_key": "", # Properties of the object. Contains field @ype with type URL.
              },
            ],
          },
          "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`
              # to this instant yields the timeout deadline for this Waiter. Output only.
        }

`list(parent=None, pageToken=None, x__xgafv=None, pageSize=None)`

    List Waiters within the given RuntimeConfig resource.

    Args:
      parent: string, The fully-qualified name of the configuration to list.
    Required. Must be a valid configuration name. (required)
      pageToken: string, The token for pagination.
      x__xgafv: string, V1 error format.
        Allowed values
          1 - v1 error format
          2 - v2 error format
      pageSize: integer, List pagination support.
    The size of the page to return. We may return fewer elements.

    Returns:
      An object of the form:

        { # Response for the `ListWaiters()` method.
          # Order of returned waiter objects is arbitrary.
        "nextPageToken": "A String", # Pagination support.
        "waiters": [ # Found waiters in the project.
          { # A Waiter resource waits for some condition within a RuntimeConfig resource
                # to be met. For example: each node in a distributed system startup process
                # writes a value to a Variable resource indicating its readiness. A Waiter
                # configured with the proper `success` condition can be used to wait until
                # some number of nodes have checked in.
                # Once created, a Waiter resource is immutable.
              "name": "A String", # Name of the variable resource.
                  # It has format of
                  # "projects/{project_id}/configs/{config_id}/waiters/{waiter_id}",
                  # Where `project_id` must be a valid Google Cloud project ID, `config_id`
                  # must be a valid RuntimeConfig object and the `waiter_id` must match
                  # RFC 1035 segment specification, and `len(waiter_id)` must be less than
                  # 64 bytes.
                  # The name is assigned by the client, but will be validated on the server
                  # side to adhere to the format.
                  # Name is immutable and cannot be changed. Required.
              "success": { # A condition that a Waiter resource is waiting for. The set of possible # The success condition. If this condition is met, `done` will be set to
                  # `true` and the `error` value will remain unset. The failure condition
                  # takes precedence over the success condition. If both conditions are met, a
                  # failure will be indicated. Required.
                  # conditions may expand over time.
                "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
                    # under the specified path prefix reaches the specified number.
                    # For example, take the following variables in a RuntimeConfig object:
                    #   /foo/variable1 = "value1"
                    #   /foo/variable2 = "value2"
                    #   /bar/variable3 = "value3"
                    #
                    # These variables would satisfy a Cardinality condition with `path` set to
                    # "/foo" and `number` set to 2, but would not satisify the same condition
                    # with `number` set to 3.
                  "path": "A String", # The root of the variable subtree to monitor. Required.
                  "number": 42, # The number of decendents of `path` that must exist before this condition
                      # is met. Optional; defaults to 1 if not specified.
                },
              },
              "failure": { # A condition that a Waiter resource is waiting for. The set of possible # The failure condition. If this condition is met, `done` will be set to
                  # `true` and the `error` code will be set to ABORTED. The failure condition
                  # takes precedence over the success condition. If both conditions are met, a
                  # failure will be indicated. This value is optional; if no failure condition
                  # is set, the only failure scenario will be a timeout. Optional.
                  # conditions may expand over time.
                "cardinality": { # The Cardinality condition is met when the count of `Variable` resources # The Cardinality condition type configuration.
                    # under the specified path prefix reaches the specified number.
                    # For example, take the following variables in a RuntimeConfig object:
                    #   /foo/variable1 = "value1"
                    #   /foo/variable2 = "value2"
                    #   /bar/variable3 = "value3"
                    #
                    # These variables would satisfy a Cardinality condition with `path` set to
                    # "/foo" and `number` set to 2, but would not satisify the same condition
                    # with `number` set to 3.
                  "path": "A String", # The root of the variable subtree to monitor. Required.
                  "number": 42, # The number of decendents of `path` that must exist before this condition
                      # is met. Optional; defaults to 1 if not specified.
                },
              },
              "done": True or False, # If the value is `false`, it means the Waiter is still waiting for one of
                  # its conditions to be met.
                  # If true, the Waiter has finished. If the Waiter finished due to a timeout
                  # or failure, `error` will be set. Output only.
              "timeout": "A String", # The timeout, beginning from the instant that CreateWaiter is called. If
                  # this timeout elapses prior to the success or failure conditions being met,
                  # the Waiter will fail and the `error` code will be set to DEADLINE_EXCEEDED.
                  # Required.
              "error": { # The `Status` type defines a logical error model that is suitable for different # If the Waiter ended due to a failure or timeout, this value will be set.
                  # Output only.
                  # 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` which 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 purpose.
                  #
                  # - 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.
                "message": "A String", # A developer-facing error message, which should be in English. Any
                    # user-facing error message should be localized and sent in the
                    # google.rpc.Status.details field, or localized by the client.
                "code": 42, # The status code, which should be an enum value of google.rpc.Code.
                "details": [ # A list of messages that carry the error details.  There will be a
                    # common set of message types for APIs to use.
                  {
                    "a_key": "", # Properties of the object. Contains field @ype with type URL.
                  },
                ],
              },
              "createTime": "A String", # The instant at which this Waiter was created. Adding the value of `timeout`
                  # to this instant yields the timeout deadline for this Waiter. Output only.
            },
        ],
      }

`list_next(previous_request, previous_response)`

    Retrieves the next page of results.

    Args:
      previous_request: The request for the previous page. (required)
      previous_response: The response from the request for the previous page. (required)

    Returns:
      A request object that you can call 'execute()' on to request the next
      page. Returns None if there are no more items in the collection.