Let me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the current state is ugly.<p>Here's the part that I don't particularly like, speaking of subtle incompatibilities:<p><pre><code> EXAMPLE 2: Multiple Values
<form enctype='application/json'>
<input type='number' name='bottle-on-wall' value='1'>
<input type='number' name='bottle-on-wall' value='2'>
<input type='number' name='bottle-on-wall' value='3'>
</form>
// produces
{
"bottle-on-wall": [1, 2, 3]
}
</code></pre>
I've seen this ugly pattern before in things that map XML to JSON. Values spontaneously convert to lists when you have more than one of them. Here come some easily overlooked type errors.<p>I don't know of any common patterns for working with "a thing or a list of things" in JSON; that kind of type mixing is the thing you hope to get away from by defining a good API. But all code that handles HTML JSON is going to have to deal with these maybe-list-maybe-not values, in a repetitive and boilerplatey way.<p>I hope that a standard such as this will eventually be adopted by real-life frameworks such as Django REST Framework, but I also hope that they just reject the possibility of multiple fields with the same name.
In fairness, you have to look at how standards get somewhere - this is an editor's draft which is a starting point of an idea rather than a done deal. Don't be surprised if the final product winds up being significantly different than this - even better, get involved in the conversation to make it what we need. That's not to pour cold water on it: It's good as it is, but there are changes which potentially help explain the magic of participating in form encoding and submission which may be better and allow more adaptation and experimentation over time.
Why such an emphasis on "losing no information" when the form is obviously malformed?<p>You need only to look at the crazy ways in which MySQL mangles data to realize that silently "correcting" invalid input is not the way to go. The web has suffered enough of that bullshit, we seriously don't need another. Example 7 (mixing scalar and array types) gives me shudders. Example 10 (mismatched braces) seems to have a reasonable fallback behavior, though I'd prefer dropping the malformed field altogether.<p>If the form is obviously malformed, transmission <i>should</i> fail, and it should fail as loudly and catastrophically as possible, so that the developer is forced to correct the mistake before the code in question ever leaves the dev box.<p>Preferably, the form shouldn't even work if any part of it is malformed. If we're too timid to do that, at least we should leave out malformed fields instead of silently shuffling them around. Otherwise we'll end up with frameworks that check three different places and return the closest match, leaving the developer blissfully ignorant of his error.<p>While we're at it, we also need strict limits on valid paths (e.g. no mismatched braces, no braces inside braces) and nesting depth (most frameworks already enforce some sort of limit there), and what to do when such limits are violated. Again, the default should be a loud warning and obvious failure, not silent mangling to make the data fit.<p>This is supposed to be a new standard, there's no backward-compatibility baggage to carry. So let's make this as clean and unambiguous as possible!
I don't agree with Example 9, we should use data uri scheme for file content<p><pre><code> "files": [{
"name": "dahut.txt",
"src": "data:text/plain;base64,REFBQUFBQUFIVVVVVVVVVVVVVCEhIQo="
}]
</code></pre>
<a href="http://en.wikipedia.org/wiki/Data_URI_scheme" rel="nofollow">http://en.wikipedia.org/wiki/Data_URI_scheme</a>
<p><pre><code> {
"name": "Bender"
, "hind": "Bitable"
, "shiny": true
}
</code></pre>
Who puts commas at the <i>start</i> of a continuing line? What good could that possibly do?
It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.
Seems pretty decent. Also neat that the nesting style could be repurposed to support nested structures in regular form-encoded HTML forms.<p>Main limitation on <i>actually</i> being able to use this is that `GET` and `POST` continue to be the only supported methods in browser form submissions right now, so eg. you wouldn't be able to make JSON `PUT` requests with this style anytime soon.<p>Might be that adoption of this would swing the consensus on supporting other HTTP methods in HTML forms.
They're still working on XForms after 10 years <a href="http://www.w3.org/MarkUp/Forms/" rel="nofollow">http://www.w3.org/MarkUp/Forms/</a>
The latest release of my jarg[0] utility supports the HTML JSON form syntax. Writing out JSON at the command line is tedious, this makes it a little nicer. The examples from the draft are compatible with jarg:<p><pre><code> $ jarg wow[such][deep][3][much][power][!]=Amaze
{"wow": {"such": {"deep": [null, null, null, {"much": {"power": {"!": "Amaze"}}}]}}}
</code></pre>
[0]: <a href="http://jdp.github.io/jarg/" rel="nofollow">http://jdp.github.io/jarg/</a>
Am I the only one who is worried about the fact that this is exponential in size?<p><pre><code> <input name="field[1000000]">
</code></pre>
Will generate a request that is ~5MB.
The JSON-based file upload would be nice (AFAIK there's not great way to do this ATM, but I haven't looked in over a year). The rest seems pretty weak-tea though. I can see multiple issues with more defined type (e.g. numeric rather than string values, null rather than blank string), but without dealing with that stuff, this seems of extremely limited utility.
A discussion about the implementation of the spec in jquery. It started on June 21<p><a href="https://github.com/macek/jquery-serialize-object/issues/24" rel="nofollow">https://github.com/macek/jquery-serialize-object/issues/24</a>
How is it solving CSRF JSON problem? <a href="http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs-json-pros-and.html" rel="nofollow">http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs...</a>
A new standard for referencing a point in a JSON object? I wonder if they considered RFC 6901 and rejected it.<p>I personally prefer this new square bracket notation, but being a standard already gets more points.
Wow, W3C at it's best again. Non-modular, non-negotiable, JSON it is, take it or leave it. Well fuck you W3C. Base64 encoded files? Seriously? What if my app workes better with msgpack encoded forms? Or with XML encoded? So you're going to support one particular serialization format, quite a horrible one, but that's subjective and that's the whole point. Every app has different needs and you should spec. out a system that is modular and leaves the choice to the user, even for the price of "complicating things".
> wow[such][deep][3][much][power][!]<p>And there goes my interest for this submission. Don't use overused memes in a submission. Liking the idea though.