Data Grid REST API

You can write and read data in different formats and Data Grid can convert between those formats when required.

The following "standard" formats are interchangeable:

You can also convert the preceding data formats into the following formats:

Data Grid also lets you convert between application/x-protostream and application/json.

All calls to the REST API can provide headers describing the content written or the required format of the content when reading. Data Grid supports the standard HTTP/1.1 headers "Content-Type" and "Accept" that are applied for values, plus the "Key-Content-Type" with similar effect for keys.

The Data Grid REST endpoint is compliant with the RFC-2616 Accept header and negotiates the correct MediaType based on the conversions supported.

For example, send the following header when reading data:

Accept: text/plain;q=0.7, application/json;q=0.8, */*;q=0.6

The preceding header causes Data Grid to first return content in JSON format (higher priority 0.8). If it is not possible to convert the storage format to JSON, Data Grid attempts the next format of text/plain (second highest priority 0.7). Finally, Data Grid falls back to */*, which picks a suitable format based on the cache configuration.

The creation of any REST resource requires a name that is part of the URL, and in case this name contains any special characters as defined in Section 2.2 of the RFC 3986 spec, it is necessary to encode it with the Percent encoding mechanism.

Most REST API calls have the Key included in the URL. Data Grid assumes the Key is a java.lang.String when handling those calls, but you can use a specific header Key-Content-Type for keys in different formats.

API call:

`PUT /my-cache/AQIDBDM=`

Headers:

Key-Content-Type: application/octet-stream

API call:

GET /my-cache/0x01CA03042F

Headers:

Key-Content-Type: application/octet-stream; encoding=hex

API call:

POST /my-cache/3.141456

Headers:

Key-Content-Type: application/x-java-object;type=java.lang.Double

The type parameter for application/x-java-object is restricted to:

When caches are indexed, or specifically configured to store application/x-protostream, you can send and receive JSON documents that are automatically converted to and from Protostream.

You must register a protobuf schema for the conversion to work.

To register protobuf schemas via REST, invoke a POST or PUT in the ___protobuf_metadata cache as in the following example:

curl -u user:password -X POST --data-binary @./schema.proto http://127.0.0.1:11222/rest/v2/caches/___protobuf_metadata/schema.proto

When writing JSON documents, a special field _type must be present in the document to identity the protobuf Message that corresponds to the document.

For example, consider the following schema:

message Person  {
  required string name = 1;
  required int32 age = 2;
}

The corresponding JSON document is as follows:

{
   "_type": "Person",
   "name": "user1",
   "age": 32
}

The VM property infinispan.server.rest.cors-allow can be used when starting the server to allow all permissions to one or more origins. Example:

./bin/server.sh -Dinfinispan.server.rest.cors-allow=http://192.168.1.78:11222,http://host.mydomain.com

All origins specified using this method will take precedence over the configured rules.

Create named caches across Data Grid clusters with POST requests that include XML or JSON configuration in the payload.

POST /rest/v2/caches/{cacheName}

<infinispan>
    <cache-container>
        <distributed-cache name="myCache" mode="SYNC">
          <encoding media-type="application/x-protostream"/>
          <memory max-count="1000000" when-full="REMOVE"/>
        </distributed-cache>
    </cache-container>
</infinispan>

{
  "distributed-cache": {
    "name": "myCache",
    "mode": "SYNC",
    "encoding": {
      "media-type": "application/x-protostream"
      },
    "memory": {
      "max-count": 1000000,
      "when-full": "REMOVE"
    }
  }
}

Check if caches are available in Data Grid clusters with HEAD requests.

HEAD /rest/v2/caches/{cacheName}

Create caches from Data Grid templates with POST requests and the ?template= parameter.

POST /rest/v2/caches/{cacheName}?template={templateName}

Retrieve Data Grid cache configurations with GET requests.

GET /rest/v2/caches/{name}?action=config

Invoke a POST request with valid XML configuration and the ?action=toJSON parameter. Data Grid responds with the equivalent JSON representation of the configuration.

POST /rest/v2/caches?action=toJSON

Invoke a GET request to retreive all details for Data Grid caches.

GET /rest/v2/caches/{name}

Data Grid provides a JSON response such as the following:

{
  "stats": {
    "time_since_start": -1,
    "time_since_reset": -1,
    "hits": -1,
    "current_number_of_entries": -1,
    "current_number_of_entries_in_memory": -1,
    "total_number_of_entries": -1,
    "stores": -1,
    "off_heap_memory_used": -1,
    "data_memory_used": -1,
    "retrievals": -1,
    "misses": -1,
    "remove_hits": -1,
    "remove_misses": -1,
    "evictions": -1,
    "average_read_time": -1,
    "average_read_time_nanos": -1,
    "average_write_time": -1,
    "average_write_time_nanos": -1,
    "average_remove_time": -1,
    "average_remove_time_nanos": -1,
    "required_minimum_number_of_nodes": -1
  },
  "size": 0,
  "configuration": {
    "distributed-cache": {
      "mode": "SYNC",
      "transaction": {
        "stop-timeout": 0,
        "mode": "NONE"
      }
    }
  },
  "rehash_in_progress": false,
  "bounded": false,
  "indexed": false,
  "persistent": false,
  "transactional": false,
  "secured": false,
  "has_remote_backup": false,
  "indexing_in_progress": false,
  "statistics": false
}

Add entries to caches with POST requests.

POST /rest/v2/caches/{cacheName}/{cacheKey}

The preceding request places the payload, or request body, in the cacheName cache with the cacheKey key. The request replaces any data that already exists and updates the Time-To-Live and Last-Modified values, if they apply.

If a value already exists for the specified key, the POST request returns an HTTP CONFLICT status and does not modify the value. To update values, you should use PUT requests. See Replacing Entries.

Replace entries in caches with PUT requests.

PUT /rest/v2/caches/{cacheName}/{cacheKey}

If a value already exists for the specified key, the PUT request updates the value. If you do not want to modify existing values, use POST requests that return HTTP CONFLICT status instead of modifying values. See Adding Values.

Retrieve data for specific keys with GET requests.

GET /rest/v2/caches/{cacheName}/{cacheKey}

The server returns data from the given cache, cacheName, under the given key, cacheKey, in the response body. Responses contain Content-Type headers that correspond to the MediaType negotiation.

GET /rest/v2/caches/{cacheName}/{cacheKey}?extended

Verify that specific entries exists with HEAD requests.

HEAD /rest/v2/caches/{cacheName}/{cacheKey}

The preceding request returns only the header fields and the same content that you stored with the entry. For example, if you stored a String, the request returns a String. If you stored binary, base64-encoded, blobs or serialized Java objects, Data Grid does not de-serialize the content in the request.

Remove entries from caches with DELETE requests.

DELETE /rest/v2/caches/{cacheName}/{cacheKey}

Remove caches from Data Grid clusters with DELETE requests.

DELETE /rest/v2/caches/{cacheName}

Invoke GET requests to retrieve all the keys in a cache in JSON format.

GET /rest/v2/caches/{cacheName}?action=keys

To delete all data from a cache, invoke a POST request with the ?action=clear parameter.

POST /rest/v2/caches/{cacheName}?action=clear

Retrieve the size of caches across the entire cluster with GET requests and the ?action=size parameter.

GET /rest/v2/caches/{cacheName}?action=size

Obtain runtime statistics for caches with GET requests.

GET /rest/v2/caches/{cacheName}?action=stats

Perform Ickle queries on caches with GET requests and the ?action=search&query parameter.

GET /rest/v2/caches/{cacheName}?action=search&query={ickle query}

Data Grid responds with query hits such as the following:

{
  "total_results" : 150,
  "hits" : [ {
    "hit" : {
      "name" : "user1",
      "age" : 35
    }
  }, {
    "hit" : {
       "name" : "user2",
       "age" : 42
    }
  }, {
    "hit" : {
       "name" : "user3",
       "age" : 12
    }
  } ]
}

To use the body of the request instead of specifying query parameters, invoke POST requests as follows:

POST /rest/v2/caches/{cacheName}?action=search

The following example shows a query in the request body:

{
 "query":"from Entity where name:\"user1\"",
 "max_results":20,
 "offset":10
}

Re-index all data in caches with POST requests and the ?action=mass-index&mode={mode} parameter.

POST  /v2/caches/{cacheName}/search/indexes?action=mass-index&mode={mode}

Values for the mode parameter are as follows:

Delete all indexes from caches with POST requests and the ?action=clear parameter.

POST  /v2/caches/{cacheName}/search/indexes?action=clear

Obtain information about indexes in caches with GET requests.

GET /v2/caches/{cacheName}/search/indexes/stats

Data Grid provides a JSON response such as the following:

{
    "indexed_class_names": ["org.infinispan.sample.User"],
    "indexed_entities_count": {
        "org.infinispan.sample.User": 4
    },
    "index_sizes": {
        "cacheName_protobuf": 14551
    },
    "reindexing": false
}

Get information about the queries that have been run in caches with GET requests.

GET /v2/caches/{cacheName}/search/query/stats

Data Grid provides a JSON response such as the following:

{
    "search_query_execution_count":20,
    "search_query_total_time":5,
    "search_query_execution_max_time":154,
    "search_query_execution_avg_time":2,
    "object_loading_total_time":1,
    "object_loading_execution_max_time":1,
    "object_loading_execution_avg_time":1,
    "objects_loaded_count":20,
    "search_query_execution_max_time_query_string": "FROM entity"
}

Reset runtime statistics with POST requests and the ?action=clear parameter.

POST /v2/caches/{cacheName}/search/query/stats?action=clear

List all available caches in Data Grid clusters with GET requests.

GET /rest/v2/caches/

Perform cross-site replication operations with the Data Grid REST API.

GET /v2/caches/{cacheName}/x-site/backups/

{
  "NYC": "online",
  "LON": "offline"
}

GET /v2/caches/{cacheName}/x-site/backups/{siteName}

{
  "NodeA":"offline",
  "NodeB":"online"
}

POST /v2/caches/{cacheName}/x-site/backups/{siteName}?action=take-offline

POST /v2/caches/{cacheName}/x-site/backups/{siteName}?action=bring-online

POST /v2/caches/{cacheName}/x-site/backups/{siteName}?action=start-push-state

POST /v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-push-state

GET /v2/caches/{cacheName}/x-site/backups?action=push-state-status

{
   "NYC":"CANCELED",
   "LON":"OK"
}

POST /v2/caches/{cacheName}/x-site/local?action=clear-push-state-status

POST /v2/caches/{cacheName}/x-site/backups/{siteName}?action=cancel-receive-state

Perform rolling upgrades of cache data between Data Grid clusters

POST /v2/caches/{cacheName}?action=sync-data

POST /v2/caches/{cacheName}?action=disconnect-source

Create counters with POST requests that include configuration in the payload.

POST /rest/v2/counters/{counterName}

{
    "weak-counter":{
        "initial-value":5,
        "storage":"PERSISTENT",
        "concurrency-level":1
    }
}

{
    "strong-counter":{
        "initial-value":3,
        "storage":"PERSISTENT",
        "upper-bound":5
    }
}

Remove specific counters with DELETE requests.

DELETE /rest/v2/counters/{counterName}

Retrieve configuration for specific counters with GET requests.

GET /rest/v2/counters/{counterName}/config

Data Grid responds with the counter configuration in JSON format.

Add values to specific counters with POST requests.

POST /rest/v2/counters/{counterName}

If the request payload is empty, the counter is incremented by one, otherwise the payload is interpreted as a signed long and added to the counter.

Retrieve counter values with GET requests.

GET /rest/v2/counters/{counterName}

Restore the intial value of counters without POST requests and the ?action=reset parameter.

POST /rest/v2/counters/{counterName}?action=reset

Increment counter values with POST request` and the ?action=increment parameter.

POST /rest/v2/counters/{counterName}?action=increment

Add arbitrary values to counters with POST requests that include the ?action=add and delta parameters.

POST /rest/v2/counters/{counterName}?action=add&delta={delta}

Decrement counter values with POST requests and the ?action=decrement parameter.

POST /rest/v2/counters/{counterName}?action=decrement

Atomically set values for strong counters with GET requests and the compareAndSet parameter.

POST /rest/v2/counters/{counterName}?action=compareAndSet&expect={expect}&update={update}

Data Grid atomically sets the value to {update} if the current value is {expect}. If the operation is successful, Data Grid returns true.

Atomically set values for strong counters with GET requests and the compareAndSwap parameter.

POST /rest/v2/counters/{counterName}?action=compareAndSwap&expect={expect}&update={update}

Data Grid atomically sets the value to {update} if the current value is {expect}. If the operation is successful, Data Grid returns the previous value in the payload.

Retrieve a list of counters in Data Grid clusters with GET requests.

GET /rest/v2/counters/

Create Protobuf schemas across Data Grid clusters with POST requests that include the content of a protobuf file in the payload.

POST /rest/v2/schemas/{schemaName}

If the schema already exists, Data Grid returns CONFLICT. If the schema is not valid, either because of syntax errors, or because some of its dependencies are missing, Data Grid stores the schema and returns the error in the response body.

Data Grid responds with the schema name and any errors.

{
  "name" : "users.proto",
  "error" : {
    "message": "Schema users.proto has errors",
    "cause": "java.lang.IllegalStateException:Syntax error in error.proto at 3:8: unexpected label: messoge"
  }
}

Retrieve Protobuf schema from Data Grid with GET requests.

GET /rest/v2/schemas/{schemaName}

Modify Protobuf schemas with PUT requests that include the content of a protobuf file in the payload.

PUT /rest/v2/schemas/{schemaName}

If the schema is not valid, either because of syntax errors, or because some of its dependencies are missing, Data Grid updates the schema and returns the error in the response body.

{
  "name" : "users.proto",
  "error" : {
    "message": "Schema users.proto has errors",
    "cause": "java.lang.IllegalStateException:Syntax error in error.proto at 3:8: unexpected label: messoge"
  }
}

Remove Protobuf schemas from Data Grid clusters with DELETE requests.

DELETE /rest/v2/schemas/{schemaName}

List all available Protobuf schemas with GET requests.

GET /rest/v2/schemas/

Data Grid responds with a list of all schemas available on the cluster.

[ {
  "name" : "users.proto",
  "error" : {
    "message": "Schema users.proto has errors",
    "cause": "java.lang.IllegalStateException:Syntax error in error.proto at 3:8: unexpected label: messoge"
  }
}, {
  "name" : "people.proto",
  "error" : null
}]

Retrieving information about Cache Managers with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}

Data Grid responds with information in JSON format, as in the following example:

{
    "version":"xx.x.x-FINAL",
    "name":"default",
    "coordinator":true,
    "cache_configuration_names":[
        "___protobuf_metadata",
        "cache2",
        "CacheManagerResourceTest",
        "cache1"
    ],
    "cluster_name":"ISPN",
    "physical_addresses":"[127.0.0.1:35770]",
    "coordinator_address":"CacheManagerResourceTest-NodeA-49696",
    "cache_manager_status":"RUNNING",
    "created_cache_count":"3",
    "running_cache_count":"3",
    "node_address":"CacheManagerResourceTest-NodeA-49696",
    "cluster_members":[
        "CacheManagerResourceTest-NodeA-49696",
        "CacheManagerResourceTest-NodeB-28120"
    ],
    "cluster_members_physical_addresses":[
        "127.0.0.1:35770",
        "127.0.0.1:60031"
    ],
    "cluster_size":2,
    "defined_caches":[
        {
            "name":"CacheManagerResourceTest",
            "started":true
        },
        {
            "name":"cache1",
            "started":true
        },
        {
            "name":"___protobuf_metadata",
            "started":true
        },
        {
            "name":"cache2",
            "started":true
        }
    ]

}

Retrieve health information for Data Grid clusters with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/health

Data Grid responds with cluster health information in JSON format, as in the following example:

{
    "cluster_health":{
        "cluster_name":"ISPN",
        "health_status":"HEALTHY",
        "number_of_nodes":2,
        "node_names":[
            "NodeA-36229",
            "NodeB-28703"
        ]
    },
    "cache_health":[
        {
            "status":"HEALTHY",
            "cache_name":"___protobuf_metadata"
        },
        {
            "status":"HEALTHY",
            "cache_name":"cache2"
        },
        {
            "status":"HEALTHY",
            "cache_name":"mycache"
        },
        {
            "status":"HEALTHY",
            "cache_name":"cache1"
        }
    ]

}

Retrieve the health status of Cache Managers with GET requests that do not require authentication.

GET /rest/v2/cache-managers/{cacheManagerName}/health/status

Data Grid responds with one of the following in text/plain format:

Verify Data Grid server REST endpoint availability with HEAD requests.

HEAD /rest/v2/cache-managers/{cacheManagerName}/health

If you receive a successful response code then the Data Grid REST server is running and serving requests.

Retrieve global configuration for Cache Managers with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/config

Retrieve the configuration for all caches with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/cache-configs

Data Grid responds with JSON arrays that contain each cache and cache configuration, as in the following example:

[
  {
      "name":"cache1",
      "configuration":{
          "distributed-cache":{
              "mode":"SYNC",
              "partition-handling":{
                  "when-split":"DENY_READ_WRITES"
              },
              "statistics":true
          }
      }
  },
  {
      "name":"cache2",
      "configuration":{
          "distributed-cache":{
              "mode":"SYNC",
              "transaction":{
                  "mode":"NONE"
              }
          }
      }
  }
]

Retrieve all available Data Grid cache templates with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/cache-configs/templates

Retrieve a list of all available caches for a Cache Manager, along with cache statuses and details, with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/caches

Data Grid responds with JSON arrays that lists and describes each available cache, as in the following example:

[ {
  "status" : "RUNNING",
  "name" : "cache1",
  "type" : "local-cache",
  "simple_cache" : false,
  "transactional" : false,
  "persistent" : false,
  "bounded": false,
  "secured": false,
  "indexed": true,
  "has_remote_backup": true,
  "health":"HEALTHY"
}, {
  "status" : "RUNNING",
  "name" : "cache2",
  "type" : "distributed-cache",
  "simple_cache" : false,
  "transactional" : true,
  "persistent" : false,
  "bounded": false,
  "secured": false,
  "indexed": true,
  "has_remote_backup": true,
  "health":"HEALTHY"
}]

Retrieve the statistics for Cache Managers with GET requests.

GET /rest/v2/cache-managers/{cacheManagerName}/stats

Data Grid responds with Cache Manager statistics in JSON format, as in the following example:

{
    "statistics_enabled":true,
    "read_write_ratio":0.0,
    "time_since_start":1,
    "time_since_reset":1,
    "number_of_entries":0,
    "total_number_of_entries":0,
    "off_heap_memory_used":0,
    "data_memory_used":0,
    "misses":0,
    "remove_hits":0,
    "remove_misses":0,
    "evictions":0,
    "average_read_time":0,
    "average_read_time_nanos":0,
    "average_write_time":0,
    "average_write_time_nanos":0,
    "average_remove_time":0,
    "average_remove_time_nanos":0,
    "required_minimum_number_of_nodes":1,
    "hits":0,
    "stores":0,
    "current_number_of_entries_in_memory":0,
    "hit_ratio":0.0,
    "retrievals":0
}

Perform cross-site operations with Cache Managers to apply the operations to all caches.

GET /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/

{
   "SFO-3":{
      "status":"online"
   },
   "NYC-2":{
      "status":"mixed",
      "online":[
         "CACHE_1"
      ],
      "offline":[
         "CACHE_2"
      ]
   }
}

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=take-offline

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=bring-online

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=start-push-state

POST /rest/v2/cache-managers/{cacheManagerName}/x-site/backups/{siteName}?action=cancel-push-state

View basic information about Data Grid servers with GET requests.

GET /rest/v2/server

Data Grid responds with the server name, codename, and version in JSON format as in the following example:

{
  "version":"Infinispan 'Codename' xx.x.x.Final"
}

Retrieve lists of cache managers for Data Grid servers with GET requests.

GET /rest/v2/server/cache-managers

Data Grid responds with an array of the cache manager names configured for the server.

Configure Data Grid to temporarily exclude specific caches from client requests. Send empty POST requests that include the names of the cache manager name and the cache.

POST /v2/server/ignored-caches/{cache-manager}/{cache}

Data Grid returns a service unavailable status (503) for REST client requests and a Server Error (code 0x85) for Hot Rod client requests.

Remove caches from the ignore list with DELETE requests.

DELETE /v2/server/ignored-caches/{cache-manager}/{cache}

Confirm that caches are ignored with GET requests.

GET /v2/server/ignored-caches/{cache-manager}

Retrieve Data Grid server configurations with GET requests.

GET /rest/v2/server/config

Data Grid responds with the configuration in JSON format, as follows:

{
    "server":{
        "interfaces":{
            "interface":{
                "name":"public",
                "inet-address":{
                    "value":"127.0.0.1"
                }
            }
        },
        "socket-bindings":{
            "port-offset":0,
            "default-interface":"public",
            "socket-binding":[
                {
                    "name":"memcached",
                    "port":11221,
                    "interface":"memcached"
                }
            ]
        },
        "security":{
            "security-realms":{
                "security-realm":{
                    "name":"default"
                }
            }
        },
        "endpoints":{
            "socket-binding":"default",
            "security-realm":"default",
            "hotrod-connector":{
                "name":"hotrod"
            },
            "rest-connector":{
                "name":"rest"
            }
        }
    }
}

Retrieve all environment variables for Data Grid servers with GET requests.

GET /rest/v2/server/env

Retrieve JVM memory usage information for Data Grid servers with GET requests.

GET /rest/v2/server/memory

Data Grid responds with heap and non-heap memory statistics, direct memory usage, and information about memory pools and garbage collection in JSON format.

Retrieve the current thread dump for the JVM with GET requests.

GET /rest/v2/server/threads

Data Grid responds with the current thread dump in text/plain format.

Retrieve aggregated reports for Data Grid servers with GET requests.

GET /rest/v2/server/report

Data Grid responds with a tar.gz archive that contains an aggregated report with diagnostic information about both the Data Grid server and the host. The report provides details about CPU, memory, open files, network sockets and routing, threads, in addition to configuration and log files.

Stop Data Grid servers with POST requests.

POST /rest/v2/server?action=stop

Data Grid responds with 200(OK) and then stops running.

Shut down entire Data Grid clusters with POST requests.

POST /rest/v2/cluster?action=stop

Data Grid responds with 200(OK) and then performs an orderly shutdown of the entire cluster.

Shut down one or more specific servers in Data Grid clusters with GET requests and the ?action=stop&server parameter.

POST /rest/v2/cluster?action=stop&server={server1_host}&server={server2_host}

Data Grid responds with 200(OK).

View a list of all configured appenders with GET requests.

GET /rest/v2/logging/appenders

Data Grid responds with a list of appenders in JSON format as in the following example:

{
  "STDOUT" : {
    "name" : "STDOUT"
  },
  "JSON-FILE" : {
    "name" : "JSON-FILE"
  },
  "HR-ACCESS-FILE" : {
    "name" : "HR-ACCESS-FILE"
  },
  "FILE" : {
    "name" : "FILE"
  },
  "REST-ACCESS-FILE" : {
    "name" : "REST-ACCESS-FILE"
  }
}

View a list of all configured loggers with GET requests.

GET /rest/v2/logging/loggers

Data Grid responds with a list of loggers in JSON format as in the following example:

[ {
  "name" : "",
  "level" : "INFO",
  "appenders" : [ "STDOUT", "FILE" ]
}, {
  "name" : "org.infinispan.HOTROD_ACCESS_LOG",
  "level" : "INFO",
  "appenders" : [ "HR-ACCESS-FILE" ]
}, {
  "name" : "com.arjuna",
  "level" : "WARN",
  "appenders" : [ ]
}, {
  "name" : "org.infinispan.REST_ACCESS_LOG",
  "level" : "INFO",
  "appenders" : [ "REST-ACCESS-FILE" ]
} ]

Create a new logger or modify an existing one with PUT requests.

PUT /rest/v2/logging/loggers/{loggerName}?level={level}&appender={appender}&appender={appender}...

Data Grid sets the level of the logger identified by {loggerName} to {level}. Optionally, it is possible to set one or more appenders for the logger. If no appenders are specified, those specified in the root logger will be used.

Remove an existing logger with DELETE requests.

DELETE /rest/v2/logging/loggers/{loggerName}

Data Grid removes the logger identified by {loggerName}, effectively reverting to the use of the root logger configuration.

View information about available server tasks with GET requests.

GET /rest/v2/tasks

Data Grid responds with a list of available tasks. The list includes the names of tasks, the engines that handle tasks, the named parameters for tasks, the execution modes of tasks, either ONE_NODE or ALL_NODES, and the allowed security role in JSON format, as in the following example:

[
  {
    "name": "SimpleTask",
    "type": "TaskEngine",
    "parameters": [
      "p1",
      "p2"
    ],
    "execution_mode": "ONE_NODE",
    "allowed_role": null
  },
  {
    "name": "RunOnAllNodesTask",
    "type": "TaskEngine",
    "parameters": [
      "p1"
    ],
    "execution_mode": "ALL_NODES",
    "allowed_role": null
  },
  {
    "name": "SecurityAwareTask",
    "type": "TaskEngine",
    "parameters": [],
    "execution_mode": "ONE_NODE",
    "allowed_role": "MyRole"
  }
]

Execute tasks with GET requests that include the task name and required parameters prefixed with param.

GET /rest/v2/tasks/myTask?action=exec&param.p1=v1&param.p2=v2

Data Grid responds with the task result.

Upload script tasks with PUT or POST requests.

Supply the script as the content payload of the request. After Data Grid uploads the script, you can execute it with GET requests.

POST /rest/v2/tasks/taskName