Roadmap

We listen to you! For any feedback or request feel free to open an issue on github.

RESTHeart 5.3

write mode

Already available in 5.3.0-SNAPSHOT

RESTHeart handles all write request with upsert semantic.

v5.3 will add the ?writeMode (and short alias ?wm) that allows:

• POST /coll?wm=insert inserts the document only if a document with same _id does not already exists (if exists, returns 409 Conflict error status code)
• POST /coll?wm=update updates only and existing document (if not existing, returns 404 Conflict error status code)
• POST /coll?wm=upsert same as current behavior

?wm works for POST (also for bulk requests), PUT, PATCH.

Simplified security

After several projects, we realized that the upsert semantic of write methods can make defining security predicates complex. To simplify security v5.3 will add a toggleable special mode where:

• POST -> can only create document(s) (same as ?wm=insert)
• PUT -> can only modify an existing document (same as ?wm=update)
• PATCH -> can only modify an existing document (same as ?wm=update)

The interceptor simplifiedSecurityWriteMode is already available in 5.3.0-SNAPSHOT. Can be enabled via the configuration and forces the writeMode as described.

As an example, let’s consider that we want to allow the user uji with role USER to only modify documents created by him. The following permission would work with simplified security but it does not currently work because PUT and PATCH can also create not existing documents (and the writeFilter does not apply on creation).

{
    "_id": { "$oid": "5d9485639eab3a852d48a1de" },
    "predicate": "path-prefix[/blog/] and (method[PUT] or method[PATCH])",
    "roles": ["editor"],
    "priority": 1,
    "readFilter": null,
    "writeFilter": { "createdBy": "%USER" }
}

v5.3 will also extend the mongoRealmAuthorizer to add role-based fields filtering and request content checker.

The following permission document, makes the field protected removed from the GET /blog response for user with role editor. It also forbids an editor to write and modify it

{
    "_id": { "$oid": "5d9485639eab3a852d48a1de" },
    "predicate": "path-prefix[/blog] and (method[GET] or method[PATCH] or method[POST])",
    "roles": ["editor"],
    "priority": 1,
    "readFilter": null,
    "writeFilter": null,
    "hide": [ "protected" ], <------
    "forbid": [ "protected", "subdoc.protected"] <------
}

v5.3 will also extend the mongoRealmAuthorizer to add role-based field override.

The following permission document, makes the field author automatically set to the user id on write requests.

{
    "_id": { "$oid": "5d9485639eab3a852d48a1de" },
    "predicate": "path-prefix[/blog] and (method[GET] or method[PATCH] or method[POST])",
    "roles": ["editor"],
    "priority": 1,
    "readFilter": null,
    "writeFilter": null,
    "hide": [ "protected" ],
    "forbid": [ "protected", "subdoc.protected"],
    "override": { "author": "%USER" } <------
}

LDAP Authenticator

The new authenticator will update the old Access Manager ADIdentityManager available for restheart 3.x to include:

• caching (extending an abstract class that simplifies implementing cached authenticators)

• configurable LDAP query to retrieve users

• compatible with Active Directory

RESTHeart 6.0

GraphQL API

The GraphQL plugin will work side by side with the already existing REST endpoints to get a managed unified GraphQL API to build modern applications.

The new service restheart-graphql will be added to RESTHeart. This service exposes a read-only (no mutations) GraphQL API for inquiring MongoDB resources.

The special collection /_gqlapps holds the GraphQL App Definitions. A GraphQL Application Definition document defines:

• application name, description and uri (the API will be available at /graphql/<uri>)

• the GraphQL schema

• mappings (information that allows to map GraphQL types and fields to MongoDB queries).

As soon as the GraphQL App Definition document gets created or updated, the GraphQL API is automatically generated and available under the security domain of RESTHeart.

RESTHeart 6.1

Support for request level replica set

readConcern, writeConcern, readPreference can be set globally with the mongo-uri.

v5.3 will add query parameters to specify those options at request level.

RESTHeart Studio

The new service restheart-studio will added to RESTHeart. This is a web application:

• for developers: to manage dbs, collections (including configuring extensions such as Transformers, Hooks, Checkers, etc), users and ACL, and reading and writing documents and files.

• for users: to manage and publishing content through forms

Released

RESTHeart 5.2

Released 11 Dec 2020

GraalVM support

RESTHeart 5.2 is GraalVM friendly.

It will be tested and supported for executing with the GraalVM and it will also allow native image builds.

Preliminary tests shows that:

• RESTHeart native image startup time is 600% faster!

• RESTHeart native image memory consumption is 1/6 (~280Mbyte vs 1.25 Gbytes).

• As expected, RESTHeart running on HotSpot JVM has better peak performances (20-30% faster). However the native image enables better overall horizontal scalability due to faster startup time and much lesser memory consumption.

RESTHeart 5.1

Released 28 May 2020

Support for Transactions

Support for Transactions has been available since RESTHeart 4.0 as a commercial plugins. With v5.1, it is available in RESTHeart OSS.

With RESTHeart 5.x we moved to the open core business model. While an enterprise license is available for legal and support requirements, all the codebase is Open Source and available under the AGPL 3.0.

Support for Change Streams

Support for Change Stream has been available since RESTHeart 4.0 as a commercial plugins. With v5.1, it is available in RESTHeart OSS.

RESTHeart 5.0

Released 6 May 2020

Single process

RESTHeart 4.x was composed by two processes: restheart-core and restheart-security. Although this simplified the development of specialized micro-services, we received many feedbacks about it being more complex to manage.

RESTHeart 5 is back to a single process. Thanks to proxying feature it is still possible deploying RESTHeart with security and mongo-services as in 4.x line.

Improved plugin development API

RESTHeart can be extended developing plugins.

Developing plugins involves implementing classes that extend interfaces and registering them.

RESTHeart 5 development API has been simplified and cleaned up.

The module restheart-commons is the only required dependency for developing plugins and it is distributed under the Apache License 2.0.

This will better clarify the legal implications of developing your custom extensions. Your extensions will only depend the more business friendly Apache License 2.0.

Easier plugin deployment

RESTHeart 5 streamlines the deployment of plugins. Copying the plugins jar file to the /plugins directory allows RESTHeart to pick it up at startup time.

RESTHeart 4.1

Released 7 October 2019

rhAuthorizer

The permissions are stored in restheart.acl collection. This way permissions can be dynamically modified without requesting to server restart.

Permission documents have the following format:

{
    "roles": [ "admin", "user" ],
    "condition": "path[/inventory] and (method[POST] or method[GET])",
    "priority": 1,
    "filters": {
        "read": {"$or": [ {"status": "PUBLISHED"}, { "author": { "$var": "username" } } ] },
        "write": {"author": {"$var": "username" }}
    }
}

This permission document means:

Allow POST and GET requests on path /inventoryfor users having role admin or user applying the following filters:

• read requests: return documents having status=PUBLISHED or author=<username of the requesting user>

• write requests: only allow requests having author=<username of the requesting user>

The filters properties allow to apply a filter (automatically added to the specified filter query parameter) to read and write requests. This allows to seamlessly partition data depending on user role.

JSON_MODE

Allows specifying the jsonMode query parameter the representation between EXTENDED (Standard extended JSON representation), RELAXED (Standard relaxed extended JSON representation) and SHELL (this output mode will attempt to produce output that corresponds to what the MongoDB shell actually produces when showing query results);

See RESTHeart Core issue 350

Support parametric conf file

Add support of mustache parameters in resthart-platform-security.yml just like RESTHeart supports it in restheart-platform-core.yml

See RESTHeart Security feature request 1