title: Rails index on show page
body: <p>What is the standard practice for a rails app when a standard 'show.html.erb' for one model essentially just lists its <code>has_many</code> of another model? There is no <code>index</code> for the 'child' model as without the context of its 'parent' model, a list of them would be useless.</p>
  
  <p>Creating /parents/1/children/1 feels like the right thing to do (especially in terms of the API) and yet on the /parents/1 page there would be nothing but a bit button saying "carry on" ... again, useless.</p>
  
  <p>Do I creat separate routes, like the one above, purely for the API or am I missing a cleaner more 'Railsy' way.</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>I'm not sure the above is totally clear.  If I have an <code>Exam</code> that was completely made up of <code>Questions</code>, would the Rails way to be to link to <code>/exam/1/questions</code> or purely to <code>/exam/1</code> with a list of questions.  Obviously the API would go to <code>/exam/1/questions</code> in most cases but what about the standard HTML page?  It would seem like it wants to be <code>/exam/1</code> but with nested resources the <code>create</code> route (by default) goes to the <code>/exam/1/questions</code> route. If there is a validation error on the <code>/exam/1/questions/new</code> route the form is rendered again on the <code>create</code> (<code>/exam/1/questions</code>) route; if the page is then refreshed you then get a 404 error as there is no index for the children.</p>
  
  <p>All this leads me to believe that Rails expects be an <code>index</code> action for the majority of models; but in the above example this feels odd.</p>