Implications of migrating several systems over from direct JDBC to a RESTful Webservice

Question

Within my department we have around 20 or so applications which use direct JDBC to obtain similar sets of financial data from the same database. I'm looking at introducing a Service to expose this financial information and then migrate the various applications over to use the Service (rather than direct JDBC). The intent here is to have data access/manipulation logic in one place such that future changes to the data model are easier to develop and co-ordinate.

Most of the clients are written in Java, with some written in C++/C# and a few shell scripts here and there.

I've heard a lot of good things about REST and so am contemplating exposing a RESTful interface rather than say SOAP.

So... I'm wondering what peoples thoughts would be with regards to a) Using REST in this type of scenario b) Scalability/Performance considerations moving away from direct JDBC c) Any other techniques / technologies which may be more appropriate for this type of thing.

Answer 1

I think in your specific case (where you control all the clients, which are just parts of the same system and (it seems) are on the same LAN) I'd lean more to put the access/logic inside the DB server, using a layer of views and stored procedures.

Ideally, those processes shouldn't have privileges to access 'raw' data, only to your views and stored procedures. Even where it's just reading a single table, if you add a 1:1 view you can later modify the behaviour without changing the clients.