Skip to content

StatusApi.md

Latest commit

 

History

History
111 lines (77 loc) · 4.03 KB

StatusApi.md

File metadata and controls

111 lines (77 loc) · 4.03 KB
Raw

corellium.StatusApi

Request timeouts

Every API method accepts _request_timeout in seconds: a positive float for the urllib3 total timeout, or a pair of positive floats (connect, read). This controls HTTP transport waiting, not how long the server operation may run. It is not a wall-clock deadline for the operation or for all retries combined.

Transport timeouts raise urllib3.exceptions.TimeoutError subclasses such as ReadTimeoutError and ConnectTimeoutError. When retries are exhausted, urllib3 can instead raise urllib3.exceptions.MaxRetryError; inspect its reason to distinguish a timeout from other connection failures. Retry behavior depends on the HTTP method and Configuration.retries. These are client-side exceptions, not HTTP response statuses or SDK ApiException responses.

A timeout does not guarantee cancellation or rollback of an operation accepted by the server. For example, after a start request times out, the instance may still be starting or may already be running; the timeout alone does not establish its state or mean it was stopped or destroyed. The request might not have reached the server at all, leaving the instance off. Treat the outcome as unknown and fetch the instance's current state before deciding whether to retry. If it has since been destroyed, that lookup may return not found; the timeout itself does not prove destruction. Do not blindly repeat a state-changing request.

Catch urllib3.exceptions.TimeoutError and urllib3.exceptions.MaxRetryError separately from the SDK ApiException. MaxRetryError is not a subclass of TimeoutError. With _with_http_info the same rules apply. With _without_preload_content, a read timeout may also occur later when reading the returned response body.

All URIs are relative to https://app.corellium.com/api

Method HTTP request Description
v3_ready GET /v3/ready Check that the API is ready

v3_ready

v3_ready()

Check that the API is ready

Health check. Returns 204 (no body) when the API is up and accepting requests, and 503 while it is shutting down. Needs no sign-in, so monitoring tools and scripts can call it before doing real work, for example to wait for a deployment to come back after an upgrade.

Example

  • Bearer (JWT) Authentication (BearerAuth):
import corellium
from corellium.rest import ApiException
from pprint import pprint

# Defining the host is optional and defaults to https://app.corellium.com/api
# See configuration.py for a list of all supported configuration parameters.
configuration = corellium.Configuration(
    host = "https://app.corellium.com/api"
)

# The client must configure the authentication and authorization parameters
# in accordance with the API server security policy.
# Examples for each auth method are provided below, use the example that
# satisfies your auth use case.

# Configure Bearer authorization (JWT): BearerAuth
configuration = corellium.Configuration(
    access_token = os.environ["BEARER_TOKEN"]
)

# Enter a context with an instance of the API client
with corellium.ApiClient(configuration) as api_client:
    # Create an instance of the API class
    api_instance = corellium.StatusApi(api_client)

    try:
        # Check that the API is ready
        api_instance.v3_ready()
    except Exception as e:
        print("Exception when calling StatusApi->v3_ready: %s\n" % e)

Parameters

This endpoint does not need any parameter.

Return type

void (empty response body)

Authorization

BearerAuth

HTTP request headers

  • Content-Type: Not defined
  • Accept: application/json

HTTP response details

Status code Description Response headers
204 API is ready for queries. -
503 API is not ready. -

[Back to top] [Back to API list] [Back to Model list] [Back to README]