RESTHeart is the Open Source data REST API server for MongoDB. Despite this definition, not only it exposes the data, but also serves static resources and custom application logic. Everything goes through its simple yaml configuration file: this is what we call piping and it is easy and effective, so that you don’t have to deal with complex deployments anymore. And more exciting features are on the way… You can find the documentation at restheart.org and fork it on github.com
Get up and running in 5 minutes
If you still don’t have RESTHeart, please refer to get up and running documentation section to quickly get ready with a running instance.
You’ll need to start RESTHeart specifying a configuration file. The download package ships with an example: <RESTHEART_HOME>/etc/restheart.yml. To use it, execute the following command:
Data resources are managed via the mongo-mounts configuration option.
The default configuration just pipes in any MongoDB resource so that the API client can, if authorized, request any db and any collection resource.
It is easy to reconfigure it, so that just some MongoDB resources are piped in.
The following configuration pipes in the collections db.c1 and db.c2, binding them to the URIs /one and /two respectively. With this configuration, RESTHeart does not expose any other MongoDB resource.
The following configuration makes accessible just the document D of the collection C of the database DB binding it to the URI /just/a/document.
The static resources are managed via the static-resources-mounts configuration option.
The following yaml fragment is the corresponding configuration:
- what: the directory path containing the static resources. Since these are embedded in the jar, this path is relative to the jar package root directory;
- where: the URI where the resources are served;
- welcome-file: the file to serve when the where URI is requested;
- secured: true if the configured RESTHeart Access Manager, if any, should be used for these resources;
- embedded true if the resources are embedded in the jar file, false if they are in the file system.
You can find another good example of piping static resources in the RESTHeart example blog application. This blog application uses the AngularJS MVC framework and RESTHeart as web server and data storage.
Its static-resources-mounts configuration section is:
This tells RESTHeart to serve the resources located in the app directory that contains the AngularJS single page web application. These are be bound to the /blog URI.
The application logic handlers are managed via the application-logic-mounts configuration option.
The default configuration pipes in two example application logic handlers. RESTHeart has a pipeline architecture where Java handlers are chained to serve the requests.
In order to provide additional application logic, custom handlers can be piped in and bound under the /_logic URI. The custom handler must extends the org.restheart.handlers.ApplicationLogicHandler class
- PingHandler is bound to /_logic/ping and implements a simple ping service
- GetRoleHandler is bound to /_logic/roles/mine and returns the current user authentication status and eventually its roles
For instance, the mentioned RESTHeart example blog application uses the GetRoleHandler (GETing the /_logic/roles/mine resource) to determine if the current user is logged in and show the login form eventually.
More to come
Release 0.9.9 will ship with the stored queries feature. This goes further in simplifying the “development” of the data API, allowing aggregation and map-reduce queries to be defined without any code development and even without touching the configuration file.
The stored queries are going to be defined as collection meta-data properties, and automatically made available to users. This approach is similar to the rels collection meta-data that makes possible defining relationships between collections so that document representations automatically include links to related documents.
For instance, the following store query makes the /db/coll/_queries/average resource available.
And, again, no complex deployment would be needed anymore; developers could just pipe logic in RESTHeart via REST calls!