Question

I am not convinced – I think it might be useful to expose your data to different consumers that can build their front-end apps on top of your webservice.

Can someone provide samples of when using web-services to wrap data-access layer is a bad idea?

Answer 1

Depending on what you define as a ‘data access layer’, there may or may not be a good reason to do it. Traditionally, distributed API’s such as web services or RPC layers live on the next layer up. This has the following advantages:

1. Without the tight coupling to the DB You can tune this layer to play nicely with distributed access – for example organising the API to minimise round trips.

2. You can put an additional layer of validation on the API. A raw data access layer may permit bad data to be written to the system. For this reason, it would be bad to expose it to untrusted clients.

3. You can put application-level security over the services layer in a way that might not be possible to a data access layer.

4. Points 1 and 2 mean that you get re-use of the business rule validations in the middle-tier.

Exposing a simple API for CRUD operations can also be achieved by directly connecting to the database server, so a web service layer over the top of this is not going to give you anything that the DBMS doesn’t already provide. Some DB engines can also directly serve queries over HTTP so you can tunnel it through most firewalls. However, the security aspects of this mean that you almost certainly don’t want to expose this to the public internet.

While you could in theory expose CRUD operations (which is what I am assuming that you mean by ‘data access layer’) through a web service, there are some fairly good reasons not to do this and relatively little benefit to doing so.