Compétences code_javascript pour la mise en œuvre du service Web d'appel inter-domaines Ajax

Récemment, ajax a rencontré des problèmes inter-domaines lors de l'accès au service Web. J'ai recherché des informations en ligne et je les ai résumées comme suit (beaucoup d'entre elles ont été copiées à partir de résumés d'autres personnes qu'ils jugeaient bons)

　a22da62c1f064432d7a0cdf17fad4154>

Commençons par mon code implémenté :

Code frontal :

$.ajax({
 type: "get",
 url: "http://localhost/Service1.asmx/getElevatorStatusJsonData?jsoncallback=?",
 dataType: "jsonp",
 jsonp: "json",
 data: "",
 success: function (result) {
 var data = eval(result);
 for (var i = 0; i < data.length; i++) {
 alert(data[i].ID + "--" + data[i].Name);
 }
 },
 error: function (a, b, c) {
 alert(c);
 }
 }); 

Code serveur :

 /// <summary>
 /// 获取状态数据信息
 /// </summary>
 /// <returns></returns>
 [WebMethod]
 public void getElevatorStatusJsonData()
 {
 List<List<DeviceInfo>> elevatordatas = new List<List<DeviceInfo>>();
 List<SendDicdate> searchList = XmlSerializeHelper.XmlDeserializeFromFile<List<SendDicdate>>(@ConfigUtil.servicePath + ConfigUtil.getConfigByKey("xmlPath") + "查询指令信息.xml", Encoding.UTF8);
 foreach (SendDicdate item in searchList)
 {
 string key = item.portno + "-" + item.bordrate + "-" + item.sendtype;
 List<DeviceInfo> deviceInfoList = (List<DeviceInfo>)Context.Cache.Get(key);
 elevatordatas.Add(deviceInfoList);
 }

 String result = "";
 DataContractJsonSerializer json = new DataContractJsonSerializer(elevatordatas.GetType());
 using (MemoryStream stream = new MemoryStream())
 {
 json.WriteObject(stream, elevatordatas);
 result = Encoding.UTF8.GetString(stream.ToArray());
 }
 String jsoncallback = HttpContext.Current.Request["jsoncallback"];
 result = jsoncallback + '(' + result + ')';
 HttpContext.Current.Response.Write(result);
 HttpContext.Current.Response.End();

 }

　c#

Ce qui précède est le code d'implémentation pour appeler le serveur c#. Ce qui suit est le côté Java. Les paramètres peuvent être différents, mais les principes sont les mêmes

.

java :

　

String callbackFunName = context.Request["callbackparam"];
　　context.Response.Write(callbackFunName + "([ { \"name\":\"John\"}])");

　 PS : Le paramètre jsonp du client est utilisé pour transmettre les paramètres via l'url, et le nom du paramètre jsonpCallback est transmis. C'est un peu difficile à prononcer. 🎜>

jsonp : ""

jsonpCallback :""

À propos : dans le navigateur Chrome, vous pouvez également définir les informations d'en-tête context.Response.AddHeader("Access-Control-Allow-Origin", "*"); côté serveur pour atteindre l'objectif de cross-country. -requêtes de domaine Et il n'est pas nécessaire de définir les paramètres ajax suivants

　

dataType : "jsonp",
　　jsonp: "callbackparam",
　　jsonpCallback:"jsonpCallback1"

Les données peuvent être obtenues via une requête ajax normale.

Ce qui suit est le principe. Après avoir lu ce que d'autres ont expliqué, cela semble logique :

1. Un problème bien connu, la demande directe Ajax pour les fichiers ordinaires pose le problème d'un accès non autorisé entre domaines, que vous soyez une page statique, une page Web dynamique, un service Web ou WCF, à condition qu'il s'agisse d'une page statique, d'une page Web dynamique, d'un service Web ou d'un WCF. est une requête inter-domaines, elle n'est pas autorisée ;

　2. Cependant, nous avons également constaté que lors de l'appel de fichiers js sur une page Web, cela n'est pas affecté par le fait qu'il s'agisse d'un inter-domaine (non seulement cela, nous avons également constaté que toutes les balises avec l'attribut "src" ont un cross-domain -capacités de domaine, telles que

3. On peut juger qu'au stade actuel, si vous souhaitez accéder aux données sur plusieurs domaines via le Web pur (les contrôles ActiveX, les proxys côté serveur, les futurs Websockets HTML5, etc. ne sont pas inclus), il n'y en a qu'un. possibilité, et c'est d'accéder aux données à distance. Le serveur essaie de charger les données dans un fichier au format js pour l'appel du client et un traitement ultérieur ;

4. Nous savons déjà qu'il existe un format de données de caractères purs appelé JSON qui peut décrire des données complexes de manière concise. Ce qui est encore mieux, c'est que JSON est également pris en charge nativement par js, de sorte que le client peut presque traiter les données dans ce format. comme souhaité ;

5. De cette façon, la solution est prête. Le client Web appelle le fichier au format js généré dynamiquement sur le serveur inter-domaines (généralement avec JSON comme suffixe) exactement de la même manière que le script appelant. Il est évident que la raison pour laquelle le serveur a besoin du but de la génération dynamique d'un fichier JSON est d'y charger les données requises par le client.

6. Une fois que le client a appelé avec succès le fichier JSON, il obtiendra les données dont il a besoin. Le reste consiste à le traiter et à l'afficher selon ses propres besoins. Cette méthode d'obtention de données à distance ressemble beaucoup à AJAX , mais c'est le cas. en fait, ce n'est pas pareil.

7. Afin de faciliter l'utilisation des données par le client, un protocole de transmission informel s'est progressivement formé. Les gens l'appellent JSONP. L'un des points clés de ce protocole est de permettre aux utilisateurs de transmettre un paramètre de rappel au serveur, et puis le serveur renvoie les données. Ce paramètre de rappel sera utilisé comme nom de fonction pour envelopper les données JSON, afin que le client puisse personnaliser sa propre fonction pour traiter automatiquement les données renvoyées.

Les développeurs intelligents peuvent facilement penser que tant que le script js fourni par le serveur est généré dynamiquement, l'appelant peut passer un paramètre pour dire au serveur "Je veux un js qui appelle le code de la fonction XXX, veuillez renvoyer it to me", afin que le serveur puisse générer des scripts js et répondre en fonction des besoins du client.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title></title><script type="text/javascript">// 得到航班信息查询结果后的回调函数var flightHandler =function(data){
 alert('你查询的航班结果是：piao价 '+ data.price +' 元，'+'余piao '+ data.tickets +' 张。');
 }; // 提供jsonp服务的url地址（不管是什么类型的地址，最终生成的返回值都是一段javascript代码）var url ="http://flightQuery.com/jsonp/flightResult.aspx&#63;code=CA1998&callback=flightHandler"; // 创建script标签，设置其属性var script = document.createElement('script');
 script.setAttribute('src', url); 
 // 把script标签加入head，此时调用开始 
//document.getElementsByTagName('head')[0].appendChild(script); 
</script></head><body></body></html>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><title>Untitled Page</title><script type="text/javascript" src=jquery.min.js"></script><script type="text/javascript">
 jQuery(document).ready(function(){
 $.ajax({
 type: "get",
 async: false,
 url: "http://flightQuery.com/jsonp/flightResult.aspx&#63;code=CA1998",
 dataType: "jsonp",
 jsonp: "callback",//传递给请求处理程序或页面的，用以获得jsonp回调函数名的参数名(一般默认为:callback) jsonpCallback:"flightHandler",//自定义的jsonp回调函数名称，默认为jQuery自动生成的随机函数名，也可以写"&#63;"，jQuery会自动为你处理数据 success: function(json){
 alert('您查询到航班信息：piao价： '+ json.price +' 元，余piao： '+ json.tickets +' 张。');
 },
 error: function(){
 alert('fail');
 }
 });
 }); </script></head><body></body></html>

N'est-ce pas un peu étrange ? Pourquoi n'ai-je pas écrit la fonction FlightHandler cette fois-ci ? Et cela a fonctionné avec succès ! Haha, c'est le mérite de jQuery. Lorsque jquery gère le type jsonp ajax (je ne peux toujours pas m'empêcher de me plaindre, bien que jquery classe également jsonp en ajax, ce n'est vraiment pas la même chose), il le génère automatiquement pour vous. N'est-il pas génial de rappeler la fonction et d'extraire les données pour que la méthode d'attribut de réussite puisse être appelée ?