title: Partial bean serialization and deserialization+merging
body: <p>I am developing a RESTful web service.</p>
  
  <p>I have a bunch of entity classes (mostly JPA entities, but also other beans).</p>
  
  <p>There are gazillions of object mapping, serialization, binding and whatnot libraries out there. I'm looking for a one that will enable me to:</p>
  
  <ul>
  <li><p><strong>Serialize the entities to XML and JSON</strong></p>
  
  <p>Serialization MUST support using <strong>getters</strong>, not only object fields.</p>
  
  <p>It MUST support <strong>views</strong>. 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 <a href="http://developer.yahoo.com/social/rest_api_guide/partial-resources.html" rel="nofollow noreferrer">Retrieving Partial Resources</a> in the Yahoo! Social Platform API. I also don't want it to recurse indefinitely deep:</p>
  
  <p>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).</p>
  
  <p>For example, the entity <code>Person</code> might have views <code>full</code> and <code>simple</code>. When requesting a <code>simple</code> view of a <code>Person</code>, only properties <code>id</code>, <code>firstName</code> and <code>lastName</code> would be serialized. When requesting a <code>full</code> view, the properties <code>mother</code> and <code>father</code> (which are <code>Persons</code> themselves) would also be serialized, but only with the <code>simple</code> view (so it wouldn't recurse to grandparents).</p>
  
  <p>The JSON serialization MUST be <strong>"natural"</strong>, 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. </p>
  
  <p>For XML, it MUST be possible to configure the serialization to use <strong>empty elements</strong> for serializing nulls, not XML Schema's <code>xsi:nil="true"</code> attributes.</p>
  
  <p>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:</p>
  
  <ul>
  <li><p>Undefined <code>friends</code> property (not present in view):</p>
  
  <pre><code>&lt;person&gt;
  &lt;/person&gt;
  </code></pre></li>
  <li><p>Empty array, person has no friends:</p>
  
  <pre><code>&lt;person&gt;
      &lt;friends&gt;&lt;/friends&gt;
  &lt;/person&gt;
  </code></pre></li>
  </ul></li>
  <li><p><strong>Deserialize XML and JSON and merge the data into existing entities</strong></p>
  
  <p>Now this is the difficult part. The next two are connected:</p>
  
  <p>Deserialization of <strong>partial objects</strong> MUST be possible (analogous to views, but which properties are present is not defined in advance).</p>
  
  <p><strong>Merging</strong> into existing properties, not creating new ones.</p>
  
  <p>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.</p>
  
  <p>When being given this XML:</p>
  
  <pre><code>&lt;person&gt;
      &lt;lastName&gt;Bon Jovi&lt;/lastName&gt;
      &lt;friends&gt;&lt;/friends&gt;
  &lt;/person&gt;
  </code></pre>
  
  <p>and being passed a <code>Person</code> object, the library should:</p>
  
  <pre><code>person.setLastName("Bon Jovi");
  person.setFriends(new ArrayList());
  </code></pre>
  
  <p>It shouldn't touch the entities <code>firstName</code> and/or clear it's <code>father</code>, for example.</p>
  
  <p>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.</p>
  
  <p>These updates/patches are a reason why the library MUST NOT just return a DTO: because at that time a <code>null</code> might either mean "unset" or "do nothing".</p></li>
  </ul>
  
  <p>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).</p>