Bolting new functionality onto older systems always has its fair share of fun and games, but exposing internal data structures to external parties is an even greater horror, this does happen though, particularly when clients want to access previously locked down systems via web services or REST interfaces or you want to deliver the same functional via new client eg B2B, mobile etc etc, I have been doing this recently with REST services using the JERSEY library, which like nearly all the good service libraries serialise and deserialise classes for you automatically, however nothing is ever perfect straight out of the box so here are some the things you can do to make your REST services perfect (these work with any JAX/Jackson implementation and often even CXF based systems)
Ill put all the code in first then explain it later (this coded represents the internal class that I am exposing via the services plus the annotations that I have added to it):
Right!, first one is name changes, i.e. you have a field who’s name is just fine in your internal class, but you want to change it when you expose it via REST services (in this case its the “id” field, this was because “id” is a reserved word under iOS which make using it a PITA for the client coders), all you have to do is put the following @annotation and the Alias you want to use just above the field you want to change, and bingo, new name ONLY for REST services
Next is date formatting, the default json date format is not loved by many people I know, and a lot of people prefer ISO 8601, you can use a custom class to do this conversion for you quite easly, again without touching the internal workings of your existing classes, just put this anotation above the ‘getter’ for that field and it will do the conversion for you on the fly (you can see the CustomDateSerializer.class code above)
Finally you can take the custom classes a bit further and change type not just class, for example converting a short form date “DD/MM/YY” stored in a String into a propper Date field. you again just declare a custom class but beef up your code and you can turn anything to anything, funky!
Looking back on this last project and talking with clients about a future one, there is maybe the option of having a dedicated set of classes for external services, far more control and more secure (as, if someone adds a field that really should NOT be exposed it wont automatically flow though to the external service), mind you if you do it that way you will have to weight up the not inconsiderable advantages of speed and easy of maintenance offered by using the internal classes.
but either way these tips might help
##### Karsten Lehmann(31/05/2012 15:37:18 GDT)
I hope you never try to use this on a Domino server with Extension Library installed. IBM picked Apache Wink as JAX-RS provider and JAX-RS only allows one per JVM (an extremely bad idea).
I did some investigation in this area when we started developing REST APIs for a framework. Somewhere in the JVM, there is a static field that contains the JAX-RS provider and this can only be set one time – with one value.
##### Mark(31/05/2012 18:07:21 GDT)
Karsten: oh poot, hmmmm, there must be a way round that, grrrrrrr
Chris: im off the booze, im on java drugs now
##### chris(31/05/2012 17:46:32 GDT)
dont understand a word of it you must be drinking something stronger than me