Let's talk about JSON and JSONP, maybe you will suddenly understand_json

Preface

Due to the characteristics of the development model of Sencha Touch 2, its native data interaction behavior can almost only be achieved through AJAX.

Of course, by calling the powerful PhoneGap plug-in and then packaging it, you can achieve 100% Socket communication and local database functions, or you can also achieve communication with the server and server push functions through HTML5 WebSocket. However, both methods have their limitations. The former requires PhoneGap support, and the latter requires that the user device must support WebSocket. Therefore, neither can be regarded as a native solution for ST2. The only native one is AJAX.

When it comes to AJAX, we will inevitably face two questions. The first is what format does AJAX use to exchange data? The second is how to solve cross-domain needs? There are currently different solutions to these two problems. For example, data can be described with custom strings or XML, and cross-domain problems can be solved through server-side proxies.

But so far, the most recommended or preferred solution is to use JSON to transmit data and rely on JSONP to cross domains. And that’s what this article is about.

Although there is only one letter difference between JSON (JavaScript Object Notation) and JSONP (JSON with Padding), they are actually not the same thing at all: JSON is a data exchange format, and JSONP is a dependency An unofficial cross-domain data exchange protocol created by the ingenuity of developers. Let's use the recent popular spy movie as an analogy. JSON is the "code" used by underground parties to write and exchange information, while JSONP is the connection method used to transmit information written in code to their comrades. Did you see that? One is to describe the format of the information, and the other is the method agreed upon by both parties for transmitting the information.

Since we are just chatting, we will no longer use a dogmatic way to tell it, but focus on helping developers understand whether they should choose to use it and how to use it.

　What is JSON

As briefly mentioned before, JSON is a text-based data exchange method, or data description format. Should you choose it first? Definitely pay attention to the advantages it has.

Advantages of JSON:

1. Based on plain text, cross-platform transmission is extremely simple;

2. Javascript native support, background Almost all languages ​​are supported;

3. Lightweight data format, occupying very few characters, especially suitable for Internet transmission;

4. Strong readability, although not as good as XML It is clear at a glance, but it is still easy to identify after reasonable indentation;

5. Easy to write and parse, of course, the premise is that you need to know the data structure;

Of course, there are also disadvantages of JSON, But in the author's opinion, it is really insignificant, so I won't explain it separately.

JSON format or rules:

JSON can describe the data structure in a very simple way. It can do everything XML can do, so it is cross-platform The two are completely indistinguishable from each other.

1. JSON has only two data type descriptors, curly brackets {} and square brackets []. The remaining English colons are mapping characters, English commas are delimiters, and English double quotes "" are delimiters. .

2. Curly brackets {} are used to describe a set of "different types of unordered key-value pair sets" (each key-value pair can be understood as an OOP attribute description), and square brackets [] are used to describe A set of "ordered data collections of the same type" (which can correspond to OOP arrays).

3. If there are multiple sub-items in the above two sets, they should be separated by commas.

4. The key-value pairs are separated by English colon:, and it is recommended that the key names be added with English double quotes "" to facilitate the analysis of different languages.

5. Commonly used data types within JSON are nothing more than strings, numbers, Boolean, dates, and null. Strings must be enclosed in double quotes, and the rest are not used. The date type is special. Here is I won’t go into details, but I just suggest that if the client does not have the function requirement of sorting by date, then just pass the date and time directly as a string, which can save a lot of trouble.

　JSON example:

Copy code The code is as follows:

//Describe a person
var person = {
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
}
// Get this person’s information
var personAge = person.Age;
// Describe several people
var members = [
{
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
},
{
"Name": "John",
"Age": 20,
"Company": "Oracle",
"Engineer": false
},
{
" Name": "Henry",
"Age": 45,
"Company": "Microsoft",
"Engineer": false
}
]
// Read Among them, John's company name
var johnsCompany = members[1].Company;
//Describe a conference
var conference = {
"Conference": "Future Marketing",
"Date ": "2012-6-1",
"Address": "Beijing",
"Members":
[
{
"Name": "Bob",
"Age": 32,
"Company": "IBM",
"Engineer": true
},
{
"Name": "John",
"Age ": 20,
"Company": "Oracle",
"Engineer": false
},
{
"Name": "Henry",
"Age": 45,
"Company": "Microsoft",
"Engineer": false
}
]
}
// Read whether the participant Henry is an engineer
var henryIsAnEngineer = conference.Members[2].Engineer;

That’s all about JSON. For more details, please refer to the information for in-depth study during the development process.

What is JSONP

Let’s first talk about how JSONP was generated:

In fact, there are many explanations about JSONP on the Internet, but they are all the same and vague. It is a bit difficult for many people who are new to it to understand. It is not a small thing, but I try to explain this problem in my own way. See if that helps.

1. A well-known problem, Ajax direct request for ordinary files has the problem of cross-domain unauthorized access. Regardless of whether you are a static page, dynamic web page, web service, or WCF, as long as it is a cross-domain request, it is not allowed;

2. However, we also found that when calling js files on a Web page, it is not affected by whether it is cross-domain (not only that, we also found that all tags with the "src" attribute have cross-domain capabilities, such as < ;script>, ,

3. It can be judged that at the current stage, if you want to access data across domains through pure web (ActiveX controls, server-side proxies, and future HTML5 Websockets are not included), there is only one possibility, and that is to remotely access data. The server tries to load the data into a js format file for client calling and further processing;

4. We happen to already know that there is a pure character data format called JSON that can describe complex data concisely. What’s even better is that JSON is also natively supported by js, so the client can process data in this format almost as desired. ;

5. In this way, the solution is ready. The web client calls the js format file dynamically generated on the cross-domain server (usually with JSON as the suffix) in exactly the same way as the calling script. It is obvious that the reason why the server needs The purpose of dynamically generating a JSON file is to load the data required by the client into it.

6. After the client successfully calls the JSON file, it will obtain the data it needs. The rest is to process and display it according to its own needs. This method of obtaining remote data looks very much like AJAX , but it’s actually not the same.

7. In order to facilitate the client to use data, an informal transmission protocol has gradually formed. People call it JSONP. One of the key points of this protocol is to allow users to pass a callback parameter to the server, and then the server returns the data. This callback parameter will be used as a function name to wrap the JSON data, so that the client can customize its own function to automatically process the returned data.

If you are still a little vague about how to use the callback parameter, we will explain it with specific examples later.

Specific implementation of JSONP client:

Regardless of jQuery, ExtJs, or other frameworks that support jsonp, the work they do behind the scenes is the same. Let me explain the implementation of jsonp on the client step by step:

1. We know that even if the code in the cross-domain js file (which of course complies with the web script security policy), the web page can be executed unconditionally.

There is a remote.js file in the root directory of remoteserver.com with the following code:

Copy the code The code is as follows:

alert('I am a remote file'); >

Copy code

The code is as follows:

< ;script type="text/javascript">


< ;/body>

Undoubtedly, a prompt window will pop up on the page, indicating that the cross-domain call was successful.

2. Now we define a function on the jsonp.html page, and then call it by passing in data in remote.js.

The jsonp.html page code is as follows:

Copy the code The code is as follows:

> ;

The remote.js file code is as follows:

Copy code The code is as follows:

localHandler({"result":"I am brought by remote js data"});

Check the results after running. The page successfully pops up a prompt window, showing that the local function was successfully called by the cross-domain remote js, and the data brought by the remote js was also received. I am very happy that the purpose of cross-domain remote data acquisition has been basically achieved, but another question arises. How do I let the remote js know the name of the local function it should call? After all, jsonp servers have to face many service objects, and the local functions of these service objects are different? Let's look down.

3. Smart developers can easily think that as long as the js script provided by the server is dynamically generated, the caller can pass a parameter to tell the server "I want to call the XXX function js code, please return it to me", so the server can generate the js script according to the client's needs and respond.

Look at the code of the jsonp.html page:

Copy the code The code is as follows:

This time the code has changed a lot. It no longer directly writes the remote js file, but codes to implement dynamic query. This is also the core part of the jsonp client implementation. The focus in this example is how to Complete the entire process of jsonp calling.

We see that a code parameter is passed in the calling url, telling the server that what I want to check is the information of flight CA1998, and the callback parameter tells the server that my local callback function is called flightHandler, so please put The query results are passed into this function for calling.

OK, the server is very smart. This page called flightResult.aspx generates a piece of code like this and provides it to jsonp.html (the server-side implementation will not be demonstrated here. It has nothing to do with the language you choose. In the final analysis, it is Splicing strings):

Copy code The code is as follows:

flightHandler({
" code": "CA1998",
"price": 1780,
"tickets": 5
});

We see that what is passed to the flightHandler function is a json, which describes the basic information of the flight. Run the page, a prompt window will pop up successfully, and the entire jsonp execution process is successfully completed!

4. By now, I believe you can understand the client implementation principle of jsonp, right? What remains is how to encapsulate the code so that it can interact with the user interface to achieve multiple and repeated calls.

What? You are using jQuery and want to know how jQuery implements jsonp calling? Okay, then I'll do it to the end and give you another piece of jQuery code using jsonp (we still use the flight information query example above, assuming that the jsonp result returned remains unchanged):

Copy code The code is as follows:

< ;script type="text/javascript">
jQuery(document).ready(function(){
$.ajax({
type: "get",
async: false,
url: "http://flightQuery.com/jsonp/flightResult.aspx?code=CA1998",
dataType: "jsonp",
jsonp: "callback",//passed to the request handler or The parameter name of the page, used to obtain the jsonp callback function name (usually the default is: callback)
jsonpCallback: "flightHandler", // Customized jsonp callback function name, the default is a random function name automatically generated by jQuery, also You can write "?", and jQuery will automatically process the data for you
success: function(json){
alert('You have found flight information: fare: ' json.price ' yuan, remaining tickets: ' json .tickets '张. ');
},
error: function(){
alert('fail');
}
});
});

Isn’t it a little weird? ? Why didn't I write the flightHandler function this time? And it actually worked successfully! Haha, this is the credit of jQuery. When jquery handles jsonp type ajax (I still can’t help but complain, although jquery also classifies jsonp into ajax, they are really not the same thing), it automatically generates it for you. Isn’t it great to call back the function and take out the data for the success attribute method to call?