Using jsonp to get interface data returns a json object, why is it a string to use ajax to get interface data?
the data is fetched from the interface, and the local test uses jsonp, to extract the json object
{
message: "suss",
item: [
{
title: "xxx"
},
{
title: "xxx"
}
]
}
then the backend says that when the interface does not support jsonp, it directly uses ajax to fetch it, but what is taken out is in the form of a string:
{
"message": "suss",
"item": [
{
"title": "xxx"
},
{
"title": "xxx"
}
]
}
also needs to be converted to an object using JSON.parse ()
what is the reason for this?
there is another problem, that is, the backend API does not support jsonp, but I test it locally, because across domains, you can only use jsonp to get the data, and you have to remove it when you go online. Is there any good way to test it locally?
specify dataType: 'json', with jQuery.ajax because the backend header does not output the correct Content-Type
the data type returned by the backend does not specify JSON. And the second one above is a reasonable JSON format. The string you said added "" to the outermost layer.
normal. The data format returned by jsonp (assuming the callback function is called callback) is originally callback ({"name": "foo"}), and the parameters in it are not in the form of a string.
when ajax transmits data, the server needs to serialize the data in json format and then pass it on. Of course, parse is needed on the client side. This library of many xhr provides the function of automatic parse. For example, jquery.ajax sets dataType to json.
< hr >
updated
does your backend say that it does not support jsonp, means that it does not support cross-domain or does not support jsonp cross-domain, which is very important.
if the backend means that jsonp is not supported, but cors, is supported, it is relatively simple. Now most mainstream xhr libraries will automatically set request headers for cors, so I won't go into details.
if the backend means that cross-domain is not supported, but if you are using devserver, locally, whether it is webpack-dev-server or express-dev-server, you can only configure proxy and add rewrite rules in devserver. There are many ways to enable proxy, including useful middleware and passing parameters, and various engineering systems are different. However, after the configuration is successful, since the server side does not have the restriction of the same origin policy, it does not matter that cross-domain is not cross-domain.
what the landlord needs now is probably: how to solve the cross-domain problem during development?
right-click chrome on the desktop, and change it to
in
goal .
"C:Program Files (x86) GoogleChromeApplicationchrome.exe"-- disable-web-security-- user-data-dir=C:Program Files (x86) GoogleChromeApplication
Note: the actual path is determined by the chrome installation path.
simply and rudely solve cross-domain problems.
Cross-domain not only can be done by jsonp, but also can be done directly by backend. Just set header
