Hi!
I am developing a RESTful web service.
I have a bunch of entity classes (mostly JPA entities, but also other beans).
There are gazillions of object mapping, serialization, binding and whatnot libraries out there. I'm looking for a one that will enable me to:
Serialize the entities to XML and JSON
Serialization MUST support using getters, not only object fields.
It MUST support views. By views I mean a way to specify a subset of the properties of the entity, which are to be serialized. For an example, see Retrieving Partial Resources in the Yahoo! Social Platform API. I also don't want it to recurse indefinitely deep:
The view should define a) properties to be exposed in the entity and b) a view for each of them (if they're entities themselves).
For example, the entity
Personmight have viewsfullandsimple. When requesting asimpleview of aPerson, only propertiesid,firstNameandlastNamewould be serialized. When requesting afullview, the propertiesmotherandfather(which arePersonsthemselves) would also be serialized, but only with thesimpleview (so it wouldn't recurse to grandparents).The JSON serialization MUST be "natural", i.e. what would make sense in Javascript. That means I want proper integers, booleans and nulls and I don't want extra object wrappers or something that tries to capture the entire XML Infoset.
For XML, it MUST be possible to configure the serialization to use empty elements for serializing nulls, not XML Schema's
xsi:nil="true"attributes.Additionally, arrays must be serialized using nested elements so it's possible to differentiate between empty arrays and properties which aren't present in a given view:
Undefined
friendsproperty (not present in view):<person> </person>Empty array, person has no friends:
<person> <friends></friends> </person>
Deserialize XML and JSON and merge the data into existing entities
Now this is the difficult part. The next two are connected:
Deserialization of partial objects MUST be possible (analogous to views, but which properties are present is not defined in advance).
Merging into existing properties, not creating new ones.
This is a bit tricky to explain. Most libraries deserialize into Java objects, but at that time, the distinction between an undefined property and a null/empty property (as it exists in Javascript/JSON, XML as described above, PHP, ...) is lost.
When being given this XML:
<person> <lastName>Bon Jovi</lastName> <friends></friends> </person>and being passed a
Personobject, the library should:person.setLastName("Bon Jovi"); person.setFriends(new ArrayList());It shouldn't touch the entities
firstNameand/or clear it'sfather, for example.Of course with lists this should be more complex. I would expect to configure an id property, by which it would decide whether to update the nested entity or create a new one.
These updates/patches are a reason why the library MUST NOT just return a DTO: because at that time a
nullmight either mean "unset" or "do nothing".
Well, that's it. I've been saying "MUST" a lot, I realize now :) The library needn't actually provide that, but there must be a way to add the functionality in a clean fashion (= not in a way that would make rewriting everything easier).