title: Java Jersey/Jackson: return dynamic JSON properties
body: <p>We use jackson to deserialize java objects (DTO's) towards JSON for our endpoints. This works well. However, I have a bit on an odd question. </p>
  
  <p>Let's say we have an object User, and we have metadata attached to this user. The metadata can really be anything the client can think of, so this is very dynamic.</p>
  
  <p>The client can make a request, to retrieve certain metadata properties of a certain user. Let's say the client wants to have the following metadata properties: age and  favouriteTree (because some people have one, right? the point is, metadata can be anything, and we don't know this beforehand).</p>
  
  <p>I would like to return the following JSON:</p>
  
  <pre><code>{
      "userId" : 1,
      "age" : 22,
      "favouriteTree" : "Maple Tree"
  }
  </code></pre>
  
  <p>I could simply have a Java POJO with an int userId, int age, and a String favouriteTree in it. This way, we can let Jackson deserialize it towards JSON and all is good. </p>
  
  <p>However, the next time the client uses the same endpoint, it might request different properties, such as: colorEyes and favouriteFood, in which case I'd want to return:</p>
  
  <pre><code>{
      "userId" : 1,
      "colorEyes" : "blue",
      "favouriteFood" : "Pizza"
  }
  </code></pre>
  
  <p>Now I would need another Java POJO for just those kind of metadata as well to deserialize it the way we normally do. But since the metadata can be anything, we can't do that, because we don't want to keep adding POJO's towards our code as different customers will have different needs.</p>
  
  <p>Is there a generic kind of way to do this in Java?</p>
  
  <p>Edit:</p>
  
  <p>I know I could do something like:</p>
  
  <pre><code>{
      "userId": 1,
      "metadata": [{
              "key": "colorEyes",
              "value": "blue"
          },
          {
              "key": "favouriteFood",
              "value": "Pizza"
          }
      ]
  }
  </code></pre>
  
  <p>But I'd like to avoid that if possible.</p>