title: How to send HTML form RESTfully?
body: <p>I have a URI for a collection of resources called 'facts', and URIs for each 'fact' resource in that collection.</p>
  
  <p>The form for creating a new 'fact' should be requested with a GET, I believe, but I'm having trouble deciding what URI it should be made to.</p>
  
  <p>A GET to the collection URI should return a list of the 'fact' resource URIs. Each 'fact' URI should return its contents as a response to GET. The actual 'fact' creation would be a POST (or PUT, depending on the situation), of course.</p>
  
  <p>I see a few options, but none seem satisfactory:</p>
  
  <ol>
  <li>Add a 'fact form' URI which the 'facts' URI will reference. A GET to this URI gives the HTML form. Seems wrong to have another resource just for a description of a resource.</li>
  <li>A POST made to the 'facts' URI without including any form data in the headers would return the form. Then after the user fills the form in, it would POST with the form data, and create the new 'fact' resource. This seems like an even worse approach.</li>
  <li>Don't send the form over the wire, but include it as part of the API. This seems RESTful since a REST API should describe the media types, and a form can be made from a description of the 'fact' type. This is weird to implement. Maybe the REST service is separate from the regular web site, so that the actual HTML form request is at some URI apart from the REST API.</li>
  <li>Include the HTML form as part of the 'facts' URI response.</li>
  </ol>
  
  <p>To clarify, I'm trying to follow true REST architecture as specified by Roy Fielding, not half-baked RPC posing as REST.</p>
  
  <p>edit: I'm starting to think #3 is on to something.</p>
  
  <p>edit2: I think a solution is to have regular non-REST HTML navigation in a CRUD manner, and then the frontend makes AJAX REST calls as appropriate (or the backend makes internal calls to its REST API).</p>
  
  <p>The reason I need to do the REST part of this service correctly is that I want to allow other non-HTML clients to interact with it later on.</p>