As in the previous form submission, our usual practice is to submit the form form, which is convenient and fast, and you don’t need to care after it is submitted. Whether it is completed or not and what to do after it is completed is the background operation after the submission, and the form form is only responsible for submitting the past. (Generally, after receiving the form submission, the backend interacts with the frontend according to the results of verification and data flow, and redirection is common).
The above is the usual practice, but sometimes there are exceptions. On a page, there is not only one form, there may be more than one form, or, after submitting the form, the user does not want the page to be refreshed, but the form submission will definitely refresh the page. Can't commit without refreshing. So, our ajax came out, and its no-refresh submission successfully solved this pain point.
Several benefits of ajax submission:
1. It is non-refreshing. After triggering a submission operation, it will not cause a bad experience due to page refresh (no refresh by default, but you can write JS for page refresh in the success event)
2. It is asynchronous. Asynchronous means that the program can continue to process other things while doing this.
There are a lot of benefits. As far as simple use is concerned, there is no form to facilitate. Writing a bunch of JS is not as easy as a submit.
There are generally two types of ajax submissions, post and get. The difference between these two forms is also explained on the Internet. The simple description is that Get is to enter the URL in the address bar to make a request. Post is processed through http requests, and post is better than get. Relatively safe. Let's talk about several ways of writing ajax.
Common spelling:
$.ajax This writing method can set some properties, such as whether to synchronize, wait time (timeout failure), cross-domain, etc.
$.post This is a short form of post request
Precautions:
When using ajax to operate data, generally ajax is asynchronous by default, so the next operation related to the current data needs to be executed in success, otherwise there may be a situation where the data cannot be obtained, and the data loaded asynchronously is generally bound to the event. It also needs to be used in conjunction with the on method, instead of simply $(obj).click(function(){});
It is worth mentioning that about the difference between the use of form and ajax, the above also said that form is more convenient to use. This is also reflected in one aspect, that is, form submission does not distinguish whether it is cross-domain or not, that is to say, submit Even if the address of the form is different from the current domain name, it also supports the submit operation, which means that you do not need to set cross-domain attributes like ajax when using the form. When ajax sets cross-domain, in addition to specifying dataType as jsonp, there are also requirements for the returned data format. First, it must be JSON data, and secondly, specify the function name. How to say it, as follows:
When back-end R&D provides an interface to colleagues responsible for front-end data rendering, if the request does not involve cross-domain, the data return format is as follows:
{“name”:”hello”}
When it comes to cross-domain operations, the required data format is as follows:
callback({“name”:”hello”})
callback is the name of the callback function, as follows:
When writing a cross-domain request in JS, the default name of jsonp is callback. If the function name in front of the data return interface of the background R&D colleague is different, it needs to be modified accordingly, otherwise the request is successful but the data cannot be obtained. In the same way, when the return format of the interface data is not in the format of "function name (JSON string)", the request will also succeed but not go to success, but go to error, and this time does not prompt the specific error ( */ω＼*) This is very unfriendly! (Only cross-domain requests will do this, and they will be ignored if they do not involve cross-domain requests)
Going back to the question just now, the form does not distinguish whether the submission is cross-domain, but the ajax distinguishes it. Why? After some online Get, I know, for the browser's consideration of JS security! We analyze from the form, when the form submits the form, just submit it, no matter whether it is successful or not, it is handed over to the background code for processing, and it does nothing by itself, even if the background returns the status information. Because the page is refreshed directly after the form is submitted, the current page is refreshed by default (most of the time it is redirected to a page from the background). But ajax is different. Ajax requests data and must get the returned result. This result can be 200, 500, or 404, but it must receive a result. In the end, ajax does not go to the success function, then it must go to the error function. , You can also check the status code returned by the current request through F12 detection browser. Generally, the status code 200 indicates that the request is OK, it will go to success, and the others will go to error (except for the wrong data format across domains, that data format is also wrong). Will request success but go with error).
Here comes the problem. Ajax obtains data from a specified address, and it submits data to get the result. Obtaining the result is also a form of obtaining data, which involves security issues. To give a simple chestnut: form submission is equivalent to me Sending courier does not ask for the result. Ajax submitting data is equivalent to sending courier but asking for a reply. Why is there a problem with ajax, because ajax will definitely receive a result, which means that when someone requests an interface 1w times, he will get 1w replies, and through this reply, hackers can find this interface You gave me your QQ number, you set a password, but I can brute force it, because every time I try the password, you will tell me that the password is wrong, and it comes with some http related information, so I have the opportunity to steal your number! But the form is different, no matter how you "fuck me", I won't give you a clear reply, you don't know whether it's a success or a failure, you can't see my preferences if you don't get my reply, so you steal the same If you don't have my account number, even if you brute force it, it's hard for you to judge whether it's right or wrong without a response. Based on this principle, browsers believe that form submission is safe by default, regardless of whether you are cross-domain or not, you can submit it casually. As for this one called ajax, since you have such unsafe behavior, you can only limit it~
To sum up, when you generally need to use partial refresh, ajax is the most suitable choice. Generally, the submission operation page will jump, and you can use the form form. Although the browser has made cross-domain restrictions on ajax for security reasons (it is said that the cross-domain attribute is actually set to be accessible, hehe), but the real problem is still in the interface, any interface exposed to the external network , the background program needs to verify and filter the parameters passed in, and then proceed to the next step.