学习记录000之跨域&&Token&&Restful设计
1.跨域
1.1什么是跨域
一张图来了解下哪些情况下存在跨域的问题
1.2解决方案
1.js解决方案
http://www.cnblogs.com/2050/p/3191744.html
2.html5具体解决方案
http://tid.tenpay.com/?p=2002
2.Token
2.1问题源
HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。
session方式暴露出以下问题：
1.Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
2.可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。
3.CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
4.CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
2.2token验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
1.用户通过用户名和密码发送请求。
2.程序验证。
3.程序返回一个签名的token 给客户端。
4.客户端储存token,并且每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态
5.服务端验证token并返回数据
2.3优势
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成 一些拥堵。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
可扩展性（）
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上。
使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。
3.Restful设计
3.1 Restful
RESTful(表现层状态转化)架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。
3.2 Restful架构
1）每一个URI代表一种资源；
2）客户端和服务器之间，传递这种资源的某种表现层；
3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
(四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源)
具体可以参考：
阮一峰理解RESTful架构
http://www.ruanyifeng.com/blog/2011/09/restful.html
3.3如何设计Restful
设计角度：域名，版本管理，路径，命名，状态码，错误处理，返回结果
可以参照以下两篇文章:
http://www.ruanyifeng.com/blog/2014/05/restful_api.html
http://blog.jobbole.com/41233/
参考文章
1.跨域http://www.ttlsa.com/web/cross-domain-solutions/
2.tokenhttp://www.sumahe.cn
