Inside RestDataware, you can create a method and publish it, creating a connection object variable (like firedac / zeos), process it and finally destroy it.
Or, you can use the one automatically configured by RESTDWDataBase. TServerMethodDataModule is always created automatically and destroyed.
As for using Firedac with cache, be careful when synchronizing when the connection returns.
Because another user can change the data that was cached on another computer, there you have to work with concurrency errors, in addition to the risk of losing launches due to the permanent loss of connection. In this case, the user complains that he made many postings and lost the records.
This cache option is great if the user continues to include / change / exclude and maintain search data, but when he returns online, you have to deal with problems that may appear.
Attention, the server should not keep too much in cache, otherwise you will have a lot of problems with high memory consumption and risk of deadlock in the tables.
In my opinion, the best thing is to keep the memory on the server side to a minimum. Because when the server goes down, or returns, everything continues.
If you had caches, there are problems with restoring the point you were on.
And that is what the REST way of working has the advantage.