Support html forms automatically

[gabrielmontagne]

Like we do on anchors, it'd be good to support forms so that we can "navigate" with other verbs and payloads than a GET with query params.

This might make some resources easier to understand and declare.
It will also help with the organization of one directional data flow resources, where the top level resource deals only with the immediate children recursively (fractally) instead of hand-wiring sibling (or cousin!) resources between themselves.

I wish we could implement this sooner rather than later, as it might make our initial examples cleaner.
And also, hopefully, our conversations about clean top-down application organazation easier to illustrate.

Would you guys, @aaronhaines @mstade @janesconference @Poetro aggree?

[mstade]

I very much agree, and also think there are many more opportunities for us to leverage hypermedia to make things cleaner and more declarative where meaningful. Forms are just one of many kinds of hypermedia controls, but it is perhaps one of the most versatile and so I definitely think it should be the priority.

What are your thoughts on interface? HTML forms are very versatile, but they lack certain features we might find key. For instance, forms according to the standard only support GET and POST and while using a different method will parse correctly it will effectively be the same as GET since the method attribute will be ignored. I don't much care what browsers do, non-JS support with resourceful apps isn't much of a priority I don't think (although not necessarily an impossibility,) but I'm unsure whether this also affects the value presented in the DOM. I.e. if someone puts method="put" in there, will put be available in the DOM in all user agents, or will it default to get?

[gabrielmontagne]

What are your thoughts on interface? HTML forms are very versatile, but they lack certain features we might find key.

First or second in google to your question was this I thought interesting post about it. If that guy's conclusion is accurate,

At this point, it seems that the main reason why there is no support for these methods is simply that nobody has taken the time to write a comprehensive specification for it

Then I'd say we could support it in the most straightforward way. You add the method and we use that method. We pass the fields that we have to the method as an object and that's it.

It might not make much sense to pass bodies to delete, but it'd be useful to have a form with just a button to "submit" that does call delete to the action specified---that'd save some JS wiring up in many cases which could then be solved purely in markup.

I think put is also quite straightforward useful, we just pass the fields and off it goes.

[mstade]

Then I'd say we could support it in the most straightforward way. You add the method and we use that method. We pass the fields that we have to the method as an object and that's it.

Agreed, but if the true value of method (as written in html) isn't available on the DOM, we have to use some auxiliary API. People do this all the time using data- attributes or hidden fields. It should be easy to verify how browsers implement parsing the <form> DOM to see if we have to do that.

(Off topic: Ian Hickson's comment on delete etc. is so annoyingly off mark. Of course a body on delete doesn't make sense, therefore it'd be trivial to spec out that user agents should ignore bodies on delete forms – using that, and similar arguments, as an excuse to not fix this egregious inconsistency is just silly.)