title: The role of Aggregate roots in a REST API (DDD)
body: <p>I'm creating a new REST/hypermedia API for an on line auction service.</p>
  
  <p>I'm using this as an exercise to better understand Domain Driven Design approach as for the most part it seems like a good approach. </p>
  
  <p>An example of some of my entities are: Item, Listing, Bid, Purchase, BidHistory etc.
  I identify the Listing entity as an aggregate root through which I plan to manage Bid, Item etc.</p>
  
  <p>As far as I can tell, the concept of the aggregate root is applicable to my persistence/domain layer and should NOT be a concern of my view layer (in my case JSON or XML resource representations). </p>
  
  <p>Is this the case? And if so, would this mean that it is still okay to expose non aggregate root resources via URI endpoints in my REST API or am I 'constrained' to only exposing aggregate roots through my API's endpoint?</p>
  
  <p>My thought is that aggregate roots are in the realm of the persistence object which is conceptually separate from the domain model and so I should be able to expose both URI such as:</p>
  
  <pre><code>GET /api/v1/listing/465489
  </code></pre>
  
  <p>and </p>
  
  <pre><code>GET /api/v1/listing/465489/item
  </code></pre>
  
  <p>regardless of whether or not Listing is the aggregate root of Item or not. </p>
  
  <p>Am I on the right lines here or do I need to adjust my understanding of this before I begin to implement any code?</p>