Setup and Configuration

The Apache Geode Developer REST interface runs as an embedded HTTP or HTTPS service (Jetty server) within one
or more Geode servers.

REST API Libraries

All Geode REST interface classes and required JAR files are distributed as a WAR file with the Geode product distribution. You can find the file in the following location:

install-dir/tools/Extensions/geode-web-api-n.n.n.war

where install-dir is the server installation directory and n.n.n is a version number.

Enabling the REST API

The REST API service for application development runs only on servers; you cannot run the service on a locator.

To enable the Developer REST API service on a given server, use the gfsh start server command with the --start-rest-api option,
or set the start-dev-rest-api property to true for the server via the ServerLauncher API.
This starts an embedded Jetty server and deploys the Developer REST API WAR file on that server.

Enabling the REST API on Multiple Servers

You can configure multiple REST-enabled servers in a single distributed system. Each server should
have a separate host name and unique end point. To ensure that the server is reachable on a
machine with multiple NIC addresses, use http-service-bind-address to bind an address to
the REST API service (as well as the other embedded web services, such as Pulse).

You can configure the Developer REST API service to run over HTTPS by enabling SSL for the http
component in gemfire.properties or gfsecurity.properties, or on server startup. See
SSL for details on configuring SSL parameters. These SSL
parameters apply to all HTTP services hosted on the configured server, which can include the
following:

Developer REST API service

Management REST API service (for remote cluster management)

Pulse monitoring tool

Starting the REST API Service

To start a REST API service-enabled Geode deployment, configure PDX serialization for your
cluster, then start the service on one or more server nodes.

Configure PDX for your cluster

You must configure PDX if either or both of the following conditions apply:

If your deployment has application peer member caches (for example, Java clients) that must also access REST-accessible Regions (resources), use the following gfsh command:

gfsh>configure pdx --read-serialized=true

Note:
You do not need to configure --read-serialized=true if no application peer member caches are accessing the REST-accessible regions (resources) in your deployment.

If your deployment contains persistent regions that must be REST-accessible, use the following gfsh command:

gfsh>configure pdx --disk-store

This command sets pdxpersistent equal to true and sets the disk-store-name to DEFAULT. If desired, specify an existing disk store name as the value for --disk-store.

If both of the above cases apply to your deployment, then configure PDX with the following single command:

gfsh>configure pdx --read-serialized=true --disk-store

After you have configured PDX for your caches, then proceed with starting your REST-enabled servers and other servers.

Start the REST API Service on One or More Servers

As described above, you can start the REST API service on a server by using gfsh start server --start-rest-api,
or by setting the Geode property start-dev-rest-api to true.
If you wish to start the service on multiple servers, use http-service-bind-address and http-service-port to
identify the cache server and specific port that will host REST services. If you do not specify
the http-service-port, the default port is 7070, which may collide with other locators and servers.
If you do not specify http-service-bind-address, the HTTP service will bind to all local addresses by default.

Note: If your application will be running in a VM (as when running in the cloud, for example),
it is good practice to specify http-service-bind-address and http-service-port so they will be
publicly visible. The default values may not be visible outside the VM in which the application is
running.

where http-service-bind-address is the address and http-service-port is the port number that you specified when starting the Development REST API service on the server. For example, based on the server started in an earlier example, you would enter:

http://localhost:8080/geode/docs/index.html

If you did not specify these properties upon server startup or in gemfire.properties, then use the
default of localhost and port 7070. See Using the Swagger UI to Browse REST
APIs for more information.

Implementing Authentication

To turn on integrated security, start your servers and locators with the security-manager property
set in your gemfire.properties file or on the gfsh command-line.
The following example uses the sample implementation that is included in the Geode source,
org.apache.geode.examples.security.ExampleSecurityManager.

This implementation requires a JSON security configuration file which defines the allowed users and their corresponding
permissions. (See the javadocs for ExampleSecurityManager for details on how to compose the JSON file.)
Place a copy of the JSON security configuration file in the execution directory of each security-enabled member, then
specify --classpath=. in the start command for each of those members.

To start a server using a username and password that are defined in that server’s security configuration, include the
--user=username and --password=password options in the server’s start command:

To contact the server through the REST interface, you must provide the username and password. Various REST GUI interfaces
provide different ways of accomplishing this. The curl command offers the --user (or -u) option for this purpose,
where username and password are specified as a colon-separated pair:

curl -i --user super-user:1234567 http://localhost:8080/geode/v1

In a simple URL, such as in a browser address bar, the credentials can be given as a prefix to the host name
in the form username:password@:

http://super-user:1234567@localhost:8080/geode/v1

Programmatic Startup

You can also start and configure Geode REST services programmatically. For example: