title: How to structure REST resource hierarchy?
body: <p>I'm new to server side web development and recently I've been reading a lot about implementing RESTful API's. One aspect of REST API's that I'm still stuck on is how to go about structuring the URI hierarchy that identifies resources that the client can interact with. Specifically I'm stuck on deciding how detailed to make the hierarchy and what to do in the case of resources being composed of other resource types.</p>
  
  <p>Here's an example that hopefully will show what I mean. Imagine we have a web service that lets users buy products from other users.  So in this simple case, there are two top level resources <strong>users</strong> and <strong>products</strong>.  Here's how I began to structure the URI hierarchy,</p>
  
  <p><strong>For users:</strong></p>
  
  <pre><code>/users
        /{id}
             /location
             /about
             /name
             /seller_rating
             /bought
             /sold
  </code></pre>
  
  <p><strong>For products:</strong></p>
  
  <pre><code>/products
           /{id}
                /name
                /category
                /description
                /keywords
                /buyer
                /seller
  </code></pre>
  
  <p>In both of these cases objects in each hierarchy reference a subset of the objects in the other hierarchy. For example <code>/users/{id}/bought</code> is a list of the products that some user has bought, which is a subset of <code>/products</code>.  Also, <code>/products/{id}/seller</code> references the user that sold a specific product.</p>
  
  <p>Since these URI's reference other objects, or subsets of other objects, should the API support things like this: <code>/users/{id}/bought/id/description</code> and <code>/products/{id}/buyer/location</code>?  Because if those types of URI's are supported, what's to stop something like this <code>/users/{id}/bought/{id}/buyer/bought/{id}/seller/name</code>, or something equally convoluted? Also, in this case, how would you handle routing since the router in the server would have to interpret URI's of arbitrary length?</p>