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.
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.