Enable the Data API Service

Step 1: Enable the WebSocket Proxy

To enable the WebSocket proxy on the required nodes, you can use SingleStore Toolbox commands on a host where SingleStore Toolbox is installed and configured. 

Before enabling WebSocket proxy, you need to obtain the MemSQL ID of the nodes for which you want to set the https_proxy_port or the http_proxy_port variable. SingleStore recommends enabling the Data API on every aggregator node in the cluster, so you will likely need the MemSQL ID of all aggregator nodes. To perform this action, run the following command.

sdb-admin list-nodes --role Master -q

Then use sdb-admin update config to set either the https_proxy_port or the http_proxy_port variable to any free port available and specify the MemSQL ID obtained for the aggregator nodes in the previous command.

For HTTPS:

sdb-admin update-config --memsql-id <nodeID> --set-global --key https_proxy_port --value <port> 

For HTTP:

sdb-admin update-config --memsql-id <nodeID> --set-global --key http_proxy_port --value <port>

Note that https_proxy_port and http_proxy_port variables are mutually exclusive and the proxy will fail to start if both are set. The https_proxy_port variable requires SSL to be enabled.

Step 2: Enable the API Endpoints

To make the API endpoints accessible on the HTTP server, run the following SingleStore Toolbox command. SingleStore recommends enabling the Data API on every aggregator node in the cluster, so you will likely need to specify the ID of each aggregator node.

sdb-admin update-config --memsql-id <nodeID> --set-global --key "http_api" --value "ON" 

If the server is already running when you update the configuration, run the following command at the SingleStore command-line for the changes to take effect.

RESTART PROXY;

Optimize the Data API Configuration

After enabling the API, you can tweak the following connection-related settings for optimum performance of the database. 

• Use the http_api_pool_capacity to limit the maximum impact of the HTTP server on the database server by limiting the maximum number of connections per user.

• Use the http_api_pool_max_idle variable to specify the maximum number of connections that can be open in each pool at any point in time. This setting helps reduce latency by holding database connections open.

For more information, refer to Non-Sync Variables List.

Test the Data API

Call the GET /ping API request to verify that the HTTP service is running and connectable. To perform this action using cURL, make a GET request to the /ping endpoint with no parameters:

curl https://localhost:8080/ping

If the Data API service is available and is able to respond to requests, you will receive the following response along with a 200 OK status code, indicating a successful HTTP response.

ping

If an error occurs, you will receive one of the HTTP response status codes, along with the error description in the response body. For more information, refer to the Data API Endpoint Reference.

The GET /ping request can only verify whether the HTTP service is running and connectable. To verify that the database can receive queries, use the /exec and /query endpoints.

The following cURL command makes a POST API request to the /query/rows endpoint. (Replace root:password in the HTTP request with your SingleStore username:password string.)

curl -H "Content-Type: application/json" --data '{"sql": "select 1+1"}' https://root:password@localhost:8080/api/v2/query/rows

If the API call is successful, you should see the following results along with a 200 OK status code.

{"results":[{"rows":[{"1+1":2}]}]}

If an error occurs, you will receive one of the HTTP response status codes, along with the error description in the response body. For more information, refer to the Data API Endpoint Reference.

If you format the JSON output with a formatting tool, the results appear as follows. (Recommended JSON formatting tools: jq, JSONLint)

{
  "results": [
    {
      "rows": [
        {
          "1+1": 2
        }
      ]
    }
  ]
}

Note: The GET /ping request should be used in automated health checks. To verify specific health metrics, use the /exec and /query endpoints.