Google Cloud RuntimeConfig API . projects . configs . waiters

Instance Methods

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

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

delete(name, x__xgafv=None)

Deletes the Waiter with the specified name.

get(name, x__xgafv=None)

Gets the Waiter resource with the specified name.

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

List Waiters within the given RuntimeConfig resource.

list_next(previous_request, previous_response)

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.