title: Should a RESTful GET response return a resource's ID?
body: <p>A number of the developers here are having a friendly (some would say religious) discussion about whether a <strong>GET request</strong> from a <strong>RESTful API</strong> should <em>return the ID of the requested resource</em>. Let's assume the following GET request:</p>
  
  <p><a href="http://my.api.com/rest/users/23" rel="noreferrer">http://my.api.com/rest/users/23</a></p>
  
  <p>This currently returns:</p>
  
  <pre><code>{"name": "Jim", "age": 40, "favoriteColor": "blue"}
  </code></pre>
  
  <p>Note that "id" is missing from the result set.</p>
  
  <p>There are basically 4 camps battling with this issue.</p>
  
  <p><strong>CAMP #1:</strong> When callers make the GET request, they already know the ID. Therefore, the result set should <strong>not</strong> include the ID. If callers need this data to enable UI editing, then callers needs to pass through the ID 23, perhaps adding the member {"id": 23} to the JSON manually.<br>
  Folks in Camp #1 also argue that the presence of the ID in the result set would indicate that this value can be modified, which of course it can't.</p>
  
  <p><strong>CAMP #2:</strong> Without the ID, the JSON result set can't be used natively for edit/update operations in UI forms. Instead, the AJAX callback mechanism needs to be responsible for passing around ID fields and manually adding these to the result set. This seems klunky and error prone. The UI guys are making the argument that the result set "feels" like it's missing data that should be present, namely the ID.</p>
  
  <p><strong>CAMP #3:</strong> These folks are concerned about consistency. If we ever have a collection of user objects returned by an API, these objects MUST include the ID. Therefore, for consistency, the singleton version of a GET should also include the ID.</p>
  
  <p><strong>CAMP #4:</strong> These folks are suggesting that the GET request for a user could return meta data in the form of HyperMedia or SelfLinks that would include the ID.</p>
  
  <p>This isn't an esoteric "Who's Right?" argument, either. The approach we take will dictate the shape of our API and affect the work loads of several developers over the new few weeks.</p>