How to send HTML form RESTfully?

Question

I have a URI for a collection of resources called 'facts', and URIs for each 'fact' resource in that collection.

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.

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.

I see a few options, but none seem satisfactory:

1. 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.
2. 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.
3. 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.
4. Include the HTML form as part of the 'facts' URI response.

To clarify, I'm trying to follow true REST architecture as specified by Roy Fielding, not half-baked RPC posing as REST.

edit: I'm starting to think #3 is on to something.

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).

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.

Answer 1

I think you're overcomplicating things a bit. A web browser is just not a perfect REST client, so you can't have a perfectly RESTful solution. In a perfect world, you would not need a form at all, because the web browser would know your media types and build the form itself.

Meanwhile, I suggest you just use what most REST frameworks would call an additional "view" on the resource to return a form:
E.g. /your/collectionresource?view=form, or /your/collectionresource;form

Answer 2

In my mind, the only cleanly RESTful answers are 1 and 3.

As I see it, the description of the resource is a resource of its own. The question is whether you want to make this resource accessible through your application's API or if you want to make it part of the API itself.

For 1, it seems RESTful make the URIs something like this:

GET /facts -> all facts GET /facts/1 -> returns fact 1 (obviously the id might be a word or something else) GET /facts/create -> returns a form appropriate for creating a fact POST /facts -> adds a fact