Welcome to the JBoss Data Grid Server
This server provides easy to use RESTful access to the Server. See below for usage details.
1. Configuration
Out of the box, JBoss Data Grid Server will use its default cache defined in <JDG_HOME>/standalone/configuration/standalone.xml . To set a custom configuration, modify the configuration file and restart JBoss Data Grid Server
Please note that the REST server only allows interaction with either the default cache, named default or one of the named caches in the configuration file. This is because the REST server starts default and pre-defined caches on startup in order to provide a more consistent behaviour.
Please also note that by default the REST server is protected using BASIC HTTP authentication. You should use the provided add-user.sh or add-user.bat scripts, depending on your platform, to add valid users. Alternatively you can configure the security subsystem for your environment. Refer to the Security subsystem documentation for further details.
The chapter in the community user guide has more details.
2. Putting data in
HTTP PUT and POST methods are used to place data in the cache - the data being the body of the request (the data can be anything you like). It is important that a Content-Type header is set.
PUT /rest/{cacheName}/{cacheKey}
A PUT request of the above URL form will place the payload (body) in the given cache, with the given key (if the cache name is new, it will be automatically initialised). For example http://someserver/rest/hr/payRoll_3 (in which case hr is the cache name, and payRoll_3 is the key). Any existing data will be replaced, and Time-To-Live and Last-Modified values will updated (if applicable).
POST /rest/{cacheName}/{cacheKey}
Exactly the same as PUT, only if a value in a cache/key already exists, it will return a HTTP CONFLICT status (and the content will not be updated).
Headers:
The following HTTP headers are supported:
| Header Name | Required? | Description |
|---|---|---|
| Content-Type | Yes | Use media/mime-types, for example "application/json" |
| timeToLiveSeconds | No | The number of seconds before this entry will automatically be deleted |
| maxIdleTimeSeconds | No | The number of seconds after last usage of this entry when it will automatically be deleted |
| performAsync | No | If true, this will return immediately, and then replicate data to the cluster on its own. Can help with bulk data inserts/large clusters. |
3. Getting data back out
HTTP GET and HEAD are used to retrieve data from entries.
GET /rest/{cacheName}/{cacheKey}
This will return the data found in the given cache name, under the given key - as the body of the response. A Content-Type header will be supplied which matches what the data was inserted as. Browsers can use the cache directly of course (e.g., as a CDN).
An ETag will be returned unique for each entry, as will the Last-Modified header field indicating the state of the data at the given URL. ETags allow browsers (and other clients) to ask for data only in the case where it has changed (to save on bandwidth) - this is standard HTTP and is honored by JBoss Data Grid Server.
HEAD /rest/{cacheName}/{cacheKey}
The same as GET, only no content is returned (only the header fields).
4. Removing data
Data can be removed at the cache key/element level, or via a whole cache name using the HTTP delete method.DELETE /rest/{cacheName}/{cacheKey}
Removes the given key name from the cache.
DELETE /rest/{cacheName}
Removes ALL the entries in the given cache name (i.e. everything from that path down).
OPTIONAL: Set the header performAsync to true to return immediately and let the removal happen in the background.