Normal form submission vs. JSON

Question

I see advantages of getting JSON response and formatting in client side but are there any advantages by using JSON for form submission compared to normal submission?

Answer 1

I didn't see any mention of file submission so I thought I'd chime in. FormData seems to be the standard way of submitting files to a server over AJAX. I didn't come across any solutions using JSON but there might be a way to serialize/deserialize files ...

Answer 2

I don't see any apparent advantages for basic form submission. But when it comes to handling complex structures you'll start to realize the advantage of organizing your data.

So if you have a simple contact form (name, email, message) stick with normal form POSTing. But think about submitting a complete user's CV for example, it's very annoying to handle the massive amount of variables in your server-side script.

Here's an example for using JSON with PHP

//Here are the submission data
{
    "personalInformation": {
        "name": "hey",
        "age": "20"
    },
    "education": {
        "entry1": {
            "type": "Collage",
            "year": "2012"
        },
        "entry2": {
            "type": "Highschool",
            "year": "2010"
        }
    }
}

$CV_Data = json_decode($_POST['json_form'], true);
$CV_Data['personalInformation']['name'];
$CV_Data['personalInformation']['age'];
//Or you can loop
foreach($CV_Data['education'] as $entry){
   $entry['type'];
   $entry['year'];
}

As you can see, using JSON here makes it a lot easier for you to work on your data.

Answer 3

I am actually wrestling with the same problem. My use case requires that a potentially complex tree to be posted to the server. Some framework are able to decode two dimensional arrays as form attributes (Spring WebMVC is one I know of). Even so, this only helps you in the specific case when you are sending a nested array. The inherent nature of name-value-pair makes it unsuitable for transmitting a tree more than one level deep. In the past, I have used hacks like sending URL-encoded JSON as attribute value:

val0=%7B%22name%22%3A%22value%22%7D&val1=something&val2=something+else

However, this approach gets messy and difficult to debug when the object becomes more complex. In addition, many frameworks provide tools that automagically map JSON form post to objects (e.g.: Jackson for Java), it seems obtuse not to take advantage of these tools.

So ultimately, the choice rests on the complexity of the object you are sending. If the object is limited to one level deep, use straight name-value-pair; if the object is complex and involves a deeply-nested tree, use JSON.

Answer 4

It probably depends on your server side application. You are usually posting data to servers using POST, so how do you format underline data depends on how do you want for your server to process it. POST provides some form of key->value protocol, while in JSON you can put more than that. You can also transfer json using GET by placing it in url.

You must look on json as a way how data is written, while normal submission with POST should give you just a way how you transport data(of course you can abuse key->value feature of it for ordering your data).

There exists protocols on top of HTTP, that could help you define interface to your web application. One good example is RESTfull http://en.wikipedia.org/wiki/Representational_state_transfer

Specifically for submitting forms, I don't see any advanatages, POST was designed for this in a first place. There are cases where you want to transmit not only data from form, but also some metadata in this case json might help you by encoding form data(with metadata) in some json format, but at the end you will be still abusing POST for transferig this json data.

Hope I answered your question.

Answer 5

One thing comes to mind when dealing with POST data is useless repetition:

For example, in POST we have this:

partners[]=Apple&partners[]=Microsoft&partners[]=Activision

We can actually see, that there is a lot of repetition here, where as when we are sending JSON:

{"partners":["Apple","Microsoft","Activision"]}

59 characters versus 47. In this small sample it looks miniscule, but these savings could go up and up, and even several bytes will save you some data. Of course, there is the parsing of data on server side, which could even out the differences, but still, i saw this sometimes helping when dealing with slower connections (looking at you, 3G and EDGE).