Best practice using XML and XSD's to map against database

Question

We have a ReST Web Service that uses POST - to insert data into database (unmarshall data from XML), and GET to retrieve data (marshalled into XML).

An XSD is used to generate Java objects (via Sun's JAXB compiler) to marshall/unmarshall data to and from a database. We kind of froze the XSD as it is, because we thought this models the data perfectly - and it does, but only for posting data really.

Now when comes the time to GET data from the database, I find myself having to "break" our current XSD and allow it to publish primary keys and other data values that POST-type requests don't care about, they are superfluous.

So - in effect the XSD now has optional elements in it (i.e those used only for GET requests). This could cause potential confusion when you have to explain to 3rd parties who want to use your web service and you have this XSD that has a kind of split personality between getting and posting data. It also doesn't feel clean and elegant as it used to.

What should I do? Is it OK to have elements in your XSD that are only used in a certain circumstances (like getting data)? Or should I have 2 XSDs - one more verbose, tailored to GET requests and one slimmed down, purely for POST request??

Your help and advice - much appreciated.

Answer 1

I was in a similar situation and created a view that I used for my "reading" purposes. I then mapped the view into the same XSD as my main tables so I could manage it all in one place. It gave me the flexibility of the "looser" reading without worry about corrupting my primary data arrangement.

Answer 2

Having fields that are only used in some contexts is OK in XML documents as long as you document it adequately. UDDI (yes I know, a thoroughly un-REST and uncool example) does just that. When you "save" or "update" an entry in UDDI, analogous to your POST and PUT, you need to supply the unique ID in the published data such that the server knows what to do with it. The advantage here is that you have one schema element and one resulting data structure to deal with for most operations on that data structure (for CRU but not always for D in UDDI). Since you are RESTful and can represent the unique identifier in the resource's URL, this approach may make less sense for your application. One thing to consider is if the retrieved data is to be passed around after retrieval. If the data needs to be self contained and is passed around within or between different contexts in your clients, then including the ID is likely helpful to the users of your service as they won't have to deal with two pieces of data (the actual data, and its unique identifier). That said, your clients may abstract away the REST/XML interaction entirely in which case, their abstraction probably already handles the ID and the remaining fields of the data structure.