title: Internal object representation when designing JSON apis
body: <p>I've got an object design question.</p>
  
  <p>I'm building a json api in Java. My system uses pojos to represent json objects and translates them from json to pojo using Jackson. Each object needs to take different forms in different contexts, and I can't decide whether to create a bunch of separate classes, one for each context, or try to make a common class work in all circumstances.</p>
  
  <p>Let me give a concrete example.</p>
  
  <p>The system has users. The api has a service to add, modify and delete uses. There is a table of users in a database. The database record looks like this:</p>
  
  <pre><code>{
    id: 123, // autoincrement
    name: "Bob",
    passwordHash: "random string",
    unmodifiable: "some string"
  }
  </code></pre>
  
  <p>When you POST/add a user, your pojo should not include an id, because that's autogenerated. You also want to be able to include a password, which gets hashed and stored in the db.</p>
  
  <p>When you PUT/update a user, your pojo shouldn't include the unmodifiable field, but it must include the id, so you know what user you're modifying.</p>
  
  <p>When you GET/retrieve the user, you should get all fields except the passwordHash.</p>
  
  <p>So the pojo that represents the user has different properties depending on whether you're adding, updating, or retrieving the user. And it has different properties in the database.</p>
  
  <p>So, should I create four different pojos in my system and translate among them? Or create one User class and try to make it look different in different circumstances, using Jackson views or some other mechanism?</p>
  
  <p>I'm finding the latter approach really hard to manage.</p>