Generic .Net Web Services

Question

At the moment we're are considering writing a number of .Net web services to export/import data between sites. There are various different types of data involved, relating to multiple database tables. I could write various web services to receive the data being sent, for example

1. ImportSomeRecord(field1, field2, field3)
2. ImportSomeRecord2(field1, field2)
3. ImportSomeRecord3(field1, field2, field3, field4, field5) and so on...

There could be about 40 of these services, and it's also possible that the fields may change i.e. new fields may be added. The client would be a VB6 application that would call the remote web service, and let that web service update the remote database. The web services will be written in VB.Net 2008.

Would it be advisable to replace all these web services with a single generic service e.g. ImportRecords(recordtype, blobofdata). I think this can be done in theory by just passing an XML string as the blob of data and letting the web service unravel this depending on the record type, but is there actually any advantage to this, and is it good practice to do so? I've read somewhere that passing XML chunks in this way, as a single parameter, isn't recommended, and I can see this also seems to be somewhat contrary to standard web service usage in that in effect I'm bypassing the web service definition.

Answer 1

Look into ADO.NET Data Services. It places a RESTful API on top of an Entity Framework model.

Answer 2

If you have a parameter as a string that just takes any old XML, how is anyone supposed to work out how to use your service without consulting some documentation?

Taking in a complex type might offer you better options as to what users can and can't pass in.