I use
headers: {'Content-Type': 'application/x-www-form-urlencoded'}
What is the correct way to send the json data so that the WS reads it correctly?
data: {
lat: '-33.4415275',
lng: '-70.6517743'
}
I have this code, I send them by post and always respond with false .
parsed in header appears like this:
lat=-33.4415275&lng=-70.6517743&singlebutton=
I imagine that the error must be there.
I think in your case it's application/json .
There are several possible values for the header Content-Type .
All allow you to send the same information in different formats since the purpose of this header is to describe to the agent what is the information format of the body you are receiving ( media type ) so you can choose an appropriate algorithm and decode it.
This header can be found in a request or response. The difference is who indicates to whom the format you are receiving. A request tells the server and a response tells the client.
Based on an object like the following
{
a: 1,
b: true,
c: [1, "a"]
}
The description of the most used values is
application/x-www-form-urlencoded
This sends the serialized data as if you had sent it in the browser url query or in a form http . This same format can be used in the body since it is a string of characters where the keys are divided by the symbol & .
This is the output of the previous object
POST /foo HTTP/1.1
Content-Length: xxxx
Content-Type: application/x-www-form-urlencoded;charset=utf8
a=1&b=true&c[]=1&c[]=a
$(function() {
var a = {
a: 1,
b: true,
c: [1, 'a']
};
console.log($.param(a));
});<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script> multipart/form-data
This is used to send files. The story behind all this is that the previous format, among other reasons, can use up to three bytes to encode a single character if it is not ASCII, so to send binary information in theory you could end up sending a file up to three times bigger than its original size. This obviously is not very efficient so this format has techniques designed specifically to deal with this problem (boundaries).
POST /foo HTTP/1.1
Content-Length: xxxx
Content-Type: multipart/form-data;boundary=-------------------------
Content-Disposition: form-data; name="a"
-------------------------974767299852498929531610575
1
-------------------------974767299852498929531610575
Content-Disposition: form-data; name="b";
-------------------------974767299852498929531610575
true
-------------------------974767299852498929531610575
Content-Disposition: form-data; name="c";
-------------------------974767299852498929531610575
1
-------------------------974767299852498929531610575
Content-Disposition: form-data; name="c";
-------------------------974767299852498929531610575
a
-------------------------974767299852498929531610575
In addition to the previous fields you can find
Content-Disposition: form-data; name="upload"; filename="ejemplo.txt"
Content-Type: text/plain
<contenido del fichero>
---------------------------974767299852498929531610575
As you can tell the header ContentType is repeated but the server interprets it correctly because it knows that it refers to the content type of the file ejemplo.txt
application/json
This uses the well-known standard JSON and the output is a string that can be deserialized into a JavaScript object with exactly the same form that was sent
POST /foo HTTP/1.1
Content-Length: xxxx
Content-Type: application/x-www-form-urlencoded;charset=utf8
{"a":1,"b":true,"c": [1, "a"]}
One of the most peculiar features of JSON is that it does not allow the use of single quotes ' and that the keys of the objects are strings of characters enclosed in double quotes "
Other popular formats are
text/HTML
image/png
application/pdf
Here is the full list of media types.
Important
Do not confuse this header with Accept that tells the agent of user what are the types of media that are willing to accept. This serves as part of the negotiation process between the client and server to determine which will be the most appropriate format to communicate with each other.