title: rest api sub resource
body: <p>I asked a similar question but perhaps it was too complicated - <a href="https://stackoverflow.com/questions/26900550/rest-api-design-for-performing-different-actions-on-an-underlying-object?noredirect=1#comment42354797_26900550">https://stackoverflow.com/questions/26900550/rest-api-design-for-performing-different-actions-on-an-underlying-object?noredirect=1#comment42354797_26900550</a></p>
  
  <p>The business rules for my system are as follows:</p>
  
  <ol>
  <li>Users can create/update a job with customer and site address (address changes for each job). A new quote automatically creates a new quote with status = new (1 quote per job only)</li>
  <li>Users can update the quote details - total, markup etc..</li>
  <li>There are several quote statuses (new, sent, on hold, won, lost). Each status needs to be accompanied by data unique to the status e.g. 'sent' requires a sent date, 'won' and 'lost' requires a decision date. When jobs are marked as won, one or more purchase order records are required against the job, so I would like to receive an array of purchase order records along with status=won.</li>
  </ol>
  
  <p>I am trying to use nouns and sub-resources as a best practice and not necessarily make the rest api match my database model but it is new and scary.</p>
  
  <pre><code>jobs (get, post)
  jobs/{id} (get, put)
  jobs/{id}/status (post, delete)
  jobs/{id}/quote  (post, put, delete)
  jobs/{id}/quote/decision (post, delete)
  </code></pre>
  
  <p>The last endpoint is where the quote status will change to won/lost etc.. The delete functionality is in case the job was accidentally marked as won/lost and needs to be returned to sent.</p>
  
  <p>Can anyone offer recommendations or insights into whether this is a good way to architect the api or am I overdoing it?</p>