Using SOAP to expose CRUD operations

Question

Is exposing CRUD operations through SOAP web services a bad idea? My instinct tells me that it is not least of which because the overhead of doing database calls overhead could be huge. I'm struggling to find documentation for/against this (anti)pattern so I was wondering if anyone could point me to some documentation or has an opinion on the matter.

Also, if anyone knows of best practises (and/or documentation to that effect) when designing soap services, that would be great.

Here's an example of how the web service would look:

• Create
• Delete
• Execute
• Fetch
• Update

And here's what the implementation would look like:

[WebMethod]
public byte[] Fetch(byte[] requestData)
{
    SelectRequest request = (SelectRequest)Deserialize(requestData);

    DbManager crudManager = new DbManager();
    object result = crudManager.Select(request.ObjectType, request.Criteria);

    return Serialize(result);
}

Answer 1

There is nothing wrong with exposing the CRUD operations via SOAP web-services per se.

You will obviously find quite a lot of examples for such services.

However depending on your particular requirements you might find that for you using SOAP is too much overhead or that you could be better off using use JSON/AJAX etc.

So I believe that unless you will provide additional details about your particular details there is no good answer for your question.

Answer 2

I think publishing a SOAP service that exposes CRUD operations to anonymous, public "users" would be a particularly bad idea. If, however, you can restrict one or both of these caveats, then I see nothing wrong with it (moreover I've implemented such services many times).

• You can require, in addition to whatever method parameters your require to perform the operation, username & password parameters that in effect authenticates the originator prior to processing the request: a failure to authenticate can be signalled with the return of a SOAP exception. If you were especially paranoid, you could optionally run the service over SSL

• You can have the server solution that deals with sending and receiving the requests filter based on IP, onyl allowing requests from a list of approved addresses.

Yes, there are overheads to running requests over SOAP (as opposed to exposing direct database access) - namely the processing time to wrap a request into a HTTP request, open a socket & send it (and the reverse at the receiving end and the again for the response) - but, it does have advantages.

Java (though the NetBeans IDE) and .Net (through VS), both support consumption of Web Services into projects / solutions - the biggest benefit of this is that objects / structures on the remote service are automatically translated into native objects in the consuming application, which is exceptionally handy.

Answer 3

If all you want to do is CRUD over the web, I'd look at some different technologies for doing REST instead of using WS*. SQL Data Services (formerly Project Astoria) might actually be a good alternative.

Answer 4

If you want to use SOAP in a RESTful manner then there is a interesting standard for this, WS-Transfer; which provides loosely coupled CRUD endpoints; from which you inspect the message and act upon your entities accordingly.

Then you can layer whatever else you want on top, WS-Secure, WS-Reliable messaging and so on.