We are using In memory data store possibly Hazecast or Redis (technology is undecided yet) Predominantly the in memory data store would be used as Cache provider , but also as computing platform for running some analytics. Hazelcast / Redis provides their own native clients that allows fine grained manipulation of the grid content. Would it be overkill to wrap the hazelcast/ redis instances in a Jetty expose a rest interface and do not provide direct access for the client applications to the Hazelcast/Redis? The responsibility of the REST Controller would be to retrieve an entry, apply a filter and on a cache miss retrieve the entry from database for example.
The functionality exposed to the applications would be Read Only + some jobs involving more than one key (analytics).
So basically the client applications are not supposed to directly update the content of the grid. Or if this will happen it will be very rare and possibly result of a Job that in any case would be running on the chosen in memory solution.
This really depends on the use case. Speaking from a Hazelcast perspective, many of the implementations we see are using an in-memory solution to reduce latency and improve throughput. A lot of effort is put into reducing the number of network hops (for example, via Smart Client capabilities that send requests directly to the cluster member hosting the data, rather than through a load balancer or master node). The REST controller introduces another network hop, as well as additional processing time. And, another potential point of failure.
So I'd say if low latency / high throughput is of primary concern, I would not introduce a REST layer.