编辑中，尚未完稿。。。2017.7.14 1345
很多前端开发出来的HTML5可能对于后台开发者来说，并不是很清楚，也许像我一样一知半解。而且真的让人很糊涂的地方就是前端的JS如何与后端的数据库进行双向通信，交互数据。
一种解释认为简单点说，这就是前端技术与后端技术沟通，根据业务定义交互接口，交互接口的的形式可能包含： 1、后端将数据输出到HTML页面，在JS控制逻辑中需要访问数据时可以从HTML中取得。 2、定义前后端请求的接口，一般是AJAX接口，如果存在跨域问题或一些特殊的业务场景，可能也会使用JSONP或者其他方式，总之，不论是何种方式请求，目的都是动态的请求数据，然后根据返回数据刷新页面内容。返回数据的格式现在主流是使用JSON格式，但是也不排除一些特殊的业务场景需要是使用XML或其他格式的数据。
对于我一样的新手，跨域请求的例子可参考、。
总之非跨域请求限制比较少，但跨域请求的限制很多。
最初XHR对象是不能跨域的，但新版本的浏览器允许跨域，但需要服务端对当前网站开权限。
在不允许跨域的年代，都是通过某些hack的方法来实现跨域的。通常是借助一些天生能够跨域的元素：script, img, iframe，这些元素里面script最好，因为可以很方便地执行JS代码，从而能够对返回的数据进行处理。
现在的互联网技术发展的越来越快，我们在开发过程中遇到的问题也越来越多。比如当我们需要进行跨域访问数据的时候该如何进行开发？本篇博文就记述如何使用Ajax进行跨域访问调用数据。
1、非跨域调用
我们用到的最多是这样的方式，也就是非跨域的进行访问，只是简单的在我们的网页中进行Ajax使用即可。如下面代码：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | /** * 非跨域请求方式 */ function feikuayu() { $.ajax({ type: "post" , url: platformUrl + "/security/modifyPwd" , data: $( '#updatepwdform' ).serialize(), dataType: "json" , success: function (data) { $( "#updatepwd_btn" ).click(); $.toast( "修改成功，系统即将退出，请重新登录" , 1500); }, error: function () { $.toast( "网络异常" , 1500); } }); } |
2、跨域请求
在我们进行跨域请求时需要改变ajax固定参数：
dataType:"jsonp",
crossDomain:true, jsonpCallback:"jsonpCallbackFun", jsonp:"callback",且后台返回的数据格式必须是：jsonpCallbackFun（json数据）; 这里的jsonpCallbackFun是你自定义的回调函数方法名。
代码如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | /** * 跨域请求方式 */ function kuayu() { $.ajax({ type: "post" , url: platformUrl + "/security/modifyPwd" , data: params, dataType: "jsonp" , crossDomain: true , jsonpCallback: "jsonpCallbackFun" , jsonp: "callback" , success: function (data) { if (data.result == 1) { $( "#updatepwd_btn" ).click(); $.toast( "修改成功，系统即将退出，请重新登录" , 1500); setTimeout( "logout()" , 1600); } else if (data.result == 2) { $.toast(data.msg, 1500); } else { $.toast( "修改失败" , 1500); } }, error: function () { $.toast( "网络异常" , 1500); } }); } |
两种协议类型
SOAP
我们知道Android网络通信的方式有两种：基于Socket和基于HTTP。基于HTTP又包括两种编程方式：HttpUrlConnection和HttpClient。
HttpURLConnection和SOAP完全是两回事，前者是网络编程方式（发送请求、获得应答），后者是一种数据传输协议，由于其基于XML，可以穿越防火墙，所以在Web Service中大受欢迎。
当比较HttpURLConnection与之之间的区别时，可以得知：
二者区别是，HttpURLConnection实现网络连接数据传输，SOAP以XML方式定义传输的数据格式（当然SOAP不光光定义数据格式，还包括方法、消息很多格式）。
其实将HTTP和SOAP放在一起比较更有意义，借用网络上的一段文字：
不同：都是底层的通信协议，请求包的格式不同而已，soap包是XML格式,http纯文本格式。
关系：SOAP是个通信协议， SOAP在HTTP协议的基础上，把编写成XML的REQUEST参数, 放在HTTP BODY上提交个WEB SERVICE服务器(SERVLET，ASP什么的) 处理完成后，结果也写成XML作为RESPONSE送回用户端， 为了使用户端和WEB SERVICE可以相互对应，可以使用WSDL作为这种通信方式的描述文件，利用WSDL工具可以自动生成WS和用户端的框架文件，SOAP具备把复杂对象序列化捆绑到XML里去的能力。
其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。
REST
REST其实并不是什么协议也不是什么标准，而是将Http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录（可能这么比喻不是很好），对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。
自己理解的将REST的思想归结以下有如下几个关键点： 1．面向资源的接口设计 所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。后面会提到有一些网站的API设计说是REST设计，其实是RPC-REST的混合体，并非是REST的思想。 2．抽象操作为基础的CRUD 这点很简单，Http中的get,put,post,delete分别对应了read,update,create,delete四种操作，如果仅仅是作为对于资源的操作，抽象成为这四种已经足够了，但是对于现在的一些复杂的业务服务接口设计，可能这样的抽象未必能够满足。其实这也在后面的几个网站的API设计中暴露了这样的问题，如果要完全按照REST的思想来设计，那么适用的环境将会有限制，而非放之四海皆准的。 3．Http是应用协议而非传输协议 这点在后面各大网站的API分析中有很明显的体现，其实有些网站已经走到了SOAP的老路上，说是REST的理念设计，其实是作了一套私有的SOAP协议，因此称之为REST风格的自定义SOAP协议。 4．无状态，自包含 这点其实不仅仅是对于REST来说的，作为接口设计都需要能够做到这点，也是作为可扩展和高效性的最基本的保证，就算是使用SOAP的WebService也是一样。
参考文章
1.