What are the differences between application/json and application/x-www-form-urlencoded?

Question

What is the difference between

request.ContentType = "application/json; charset=utf-8";

and

webRequest.ContentType = "application/x-www-form-urlencoded";

Bergstrom

Related post -application/x-www-form-urlencoded or multipart/form-data? – Afield

Answer 1

The first case is telling the web server that you are posting JSON data as in:

{"Name": "John Smith", "Age": 23}

The second case is telling the web server that you will be encoding the parameters in the URL:

Name=John+Smith&Age=23

Pastrami

What implications does it have on the server side. I see sites like stackoverflow & Twitter use x-www-form-urlencoded for AJAX requests like vote etc. The response sent back is JSON. I would think that it's better to have a symmetrical request/response pair i.e. both JSON. – Halifax

@AdamJohns : This blog is worth reading although it doesn't exactly answer the "why" : homakov.blogspot.in/2012/06/… – Halifax

@buffer My understanding is using JSON as contentType helps when the data to be sent is more complex and involves a lot of hierarchy.. whereas form encoded is good to send simple params in url which can be read at the backend without to much code... I guess this answers the why part of it. – Felske

@Medorator A late comment. Though for example, when you're sending a complex JSON object with an array of objects in it, using application/x-www-form-urlencoded would confuse the server (Elixir using Poison in my case) and result in some inappropriate parsing of the object (it somehow converted the nested array of objects to a map, instead of a list). Using application/json should be the correct choice in this case. – Saxecoburggotha

Answer 2

webRequest.ContentType = "application/x-www-form-urlencoded";

1. Where does application/x-www-form-urlencoded's name come from?

   If you send HTTP GET request, you can use query parameters as follows:

   http://example.com/path/to/page?name=ferret&color=purple

   The content of the fields is encoded as a query string. The application/x-www-form- urlencoded's name come from the previous url query parameter but the query parameters is in where the body of request instead of url.

   The whole form data is sent as a long query string.The query string contains name- value pairs separated by & character

   e.g. field1=value1&field2=value2

2. It can be simple request called simple - don't trigger a preflight check

   Simple request must have some properties. You can look here for more info. One of them is that there are only three values allowed for Content-Type header for simple requests

   • application/x-www-form-urlencoded
   • multipart/form-data
   • text/plain

3.For mostly flat param trees, application/x-www-form-urlencoded is tried and tested.

request.ContentType = "application/json; charset=utf-8";

1. The data will be json format.

axios and superagent, two of the more popular npm HTTP libraries, work with JSON bodies by default.

{
  "id": 1,
  "name": "Foo",
  "price": 123,
  "tags": [
    "Bar",
    "Eek"
  ],
  "stock": {
    "warehouse": 300,
    "retail": 20
  }
}

2. "application/json" Content-Type is one of the Preflighted requests.

Now, if the request isn't simple request, the browser automatically sends a HTTP request before the original one by OPTIONS method to check whether it is safe to send the original request. If itis ok, Then send actual request. You can look here for more info.

3. application/json is beginner-friendly. URL encoded arrays can be a nightmare!

Jaclyn

Although application/json is beginner-friendly, is it okay to use it in a production server? The front-end is not a website in my case, it is a mobile application – Prase

it is perfectly fine to use JSON for your requests, to and fro – Hoick

Answer 3

One of the biggest differences between the two is that JSON-encoding the post usually preserves the data types of the values that are sent in (as long as they are valid JSON datatypes), whereas application/x-www-form-urlencoded will usually have all properties converted to strings.

For example, in the JSON-encoded post of:

{"Name": "John Smith", "Age": 23}

the server will most likely parse the Age property as the integer 23.

Whereas in

Name=John+Smith&Age=23

the server will most likely parse Age as the string "23".

Of course, if you are using other layers to parse these values and convert them to the appropriate types, this may not be an issue.

Replicate