title: ASP.NET Web Api Best Practice for long Creating, Polling, Deliverying long running jobs
body: <p>We are working on a new RESTful api using ASP.NET Web API.  Many of our customers receive a nightly datafeed from us. For each feed we run a schedule SQL Agent job that fires off a stored procedure which executes an SSIS package and delivers files via Email/FTP. Several customers would benefit from being able to run this job on demand and then receive either their binary file (xml, xls, csv, txt, etc.) or a direct transfer of the data in JSON or XML.</p>
  
  <p>The main issue is that the feeds generally take a while to run.  Most run within a few minutes but there are a couple that can take 20 minutes (part of the project is optimizing these jobs).  I need some help finding a best practice for setting up this api.  </p>
  
  <p>Here are our actions and proposed REST calls</p>
  
  <p><strong>Create Feed Request</strong></p>
  
  <pre><code>POST ./api/feedRequest
  Status 201 Created 
  </code></pre>
  
  <p>Returns feedID in the body (JSON or XML)</p>
  
  <p>We thought POST would be the correct request type because we're creating a new request.  </p>
  
  <p><strong>Poll Feed Status</strong>
  GET ./api/feedRequest/{feedID}</p>
  
  <pre><code>Status 102 Processing (feed is processing)
  Status 200 OK (feed is completed)
  </code></pre>
  
  <p><strong>Cancel Feed Request</strong></p>
  
  <pre><code>DELETE .api/feedRequest/{feedID}
  Status 204 No Content
  </code></pre>
  
  <p>Cancels feed request. </p>
  
  <p><strong>Get Feed</strong></p>
  
  <pre><code>GET .api/feed/{feedID}
  Status 200 OK
  </code></pre>
  
  <p>This will return the feed data. We'll probably pass parameters into the header to specify how they want their data.  Setting feedType to "direct" would require JSON or XML setting in Content-Type.  Setting feedType to "xml", "xls", "csv", etc., will transfer a binary data file back to the user.  For some feeds this is a custom template that is specified in the feed definition already stored in our tables.</p>
  
  <p><strong>Questions</strong></p>
  
  <ol>
  <li><p>Does it appear that we're on the right track?  Any immediate suggestions or concerns?</p></li>
  <li><p>We are trying to decide whether to have a /feed resource and a /feedRequest resource or whether to keep it all under /feed.  The above scenario is the two resource approach.  The single resource would POST /feed to start request, PUT /feed to check the status, GET /feed when it's done.  The PUT doesn't feel right and right now we're leaning towards the stated solution above.  Does this seem right?</p></li>
  <li><p>We're concerned about very large dataset returns. Should we be breaking these into pieces or will REST service handle these large returns.  Some feeds can be in excess of 100MB.</p></li>
  <li><p>We also have images that may be generated to accompany the feed, they're zipped up in a separate file when the feed stored procedure and package are called. We can keep this all in the same request and call GET /feed/{feedID}/images on the return. </p></li>
  <li><p>Does anyone know of a Best Practice or a good GitHub example we could look at that does something similar to this with MS technologies?  (We considered moving to ASP.NET Core as well.</p></li>
  </ol>