字数-2240
RESTful
RESTful风格应用已经有些年头，回头综合来看，跟传统的web service/普通http请求，愚以为有几下特点：
-
它是开放式的纯接口支撑，无状态。
-
充分利用了HTTP的请求类型和HTTP状态字，一URL对应多接口，由状态字反应业务处理结果。传统的HTTP做法估计就是每个接口对应不同的URL，返回的都是HTTP 200结果，然后在结果里根据内容甄别对错。
-
大量的基于JAX-RS规范（对应的JCP标准是JSR 339）的实现框架已经起来，jersey开发RESTful风格的接口，参数和结果支持灵活对象化，扩展的filter统一处理权限等问题，配合注解权限配置又可以在接口上灵活化；spring web里的REST template也能灵活调用RESTFul接口，对异常的处理也可抽象出独立的handler。
-
RESTful接口的权限设计更好理解，url即资源，每个每个业务也抽象成资源的概念。
更好的理解RESTful见，Roy Fielding博士的论文，以及阮先生的博文。几篇wifi也是好的资料：wiki1/wiki2/wiki3
auth2.0
用什么来保证RESTful接口的安全性？主流的做法Auth 2.0，使用Bearer Token进行身份验证，关于Bearer Token的一些用法，这里有说明。
很多auth 2.0的实现，比较地偏于整体方案。下文将介绍：
- 对auth 2.0的基本理解；
- 了解第三方微信登录功能；
- 参照微信登录，自己实现的数据服务端restful接口，用以实现后端程序分离。
2.1 对auth 2.0的基本理解
根据RFC 6749的描述，auth 2.0解决的问题就是资源服务与认证服务可分离，资源服务依赖于认证服务提供的访问凭证。auth2.0授权模式有多种，授权码模式的具体的处理流程如下图：
以上的User Agent/Client，不是很好理解，结合下文的微信登录流程可能就会比较具体化。没理解错的话，Client指面向用户的资源服务程序，比如某APP，User Agent指第三方（即认证方？）跟用户交互的页面或接口，比如A为扫码页面，B1为确认登录（未确认身份之前），B2为直接获取资源（这才是最终的目的），CDE为资源服务程序（后台）与认证服务之间的往来。这里就有一个问题了，既然Client为资源服务方，那为什么还有B2这个过程？除非B2是第三方的资源，才需要第三方的接口或页面。
微信登录的流程是什么样的呢？用flowchat生成的流程图如下（refresh token有效的分支缺，因为生成的图不好看去掉了）：
图中的认证资源即指获取微信用户昵称、OPEN ID/UNION ID等。这里有一点非常大的疑惑，access token放在url里不担心泄漏的问题吗？
2.2 实现RESTFul调用者鉴权
仿微信登录的auth 2.0，我实现了以下鉴权功能，更多情况在这里：
除了授权相关的接口，其它几乎所有的接口调用的时候都需要带上授权信息，即app id和access token。基本的流程如下：
1). 根据颁发的app id请求获得code，code的有效期为5分钟
2). 根据code及app id、app secret key获得access token和refresh token，access token的有效期为2小时，refresh token的有效期为30天
3). 根据app id、access token去访问授信资源
4). 根据refresh token去进行access token的续期