服务端接口设计,App架构设计

安全机制的设计:

现在大部分的App接口的设计都是采用RESTful,而RESTful的设计的原则是客户端与服务端的交互是无状态的.也就是说,如果要做用户校验,那么每次请求都要带上验证信息.那么一般实现为token:

1.用户用密码成功登陆后,服务器返回token给客户端
2.客户端将token保存到本地,发起后续的请求后时,将token返回给服务端.
3.服务器检查token的有效性,有效则返回数据,若无效,那么分为两种情况:
①token错误,这时需要用户重新登录,返回给正确的token
②token过期,这时客户端需重新发起一次认证请求,获取正确的token

然后,这种方式存在一个严重的安全性问题,当登录的接口被劫持时,黑客就可以得到用户的账号和密码以及token.后续就可以为所欲为了,而真正的用户只有通过修改密码来夺回主权.

优化的两种方式:

1.Https:在Http的基础上增加了SSL的安全协议.自动对数据进行了安全加密,在一定程度可以防止监听,防止劫持,防止重发,安全性能提高了很多.不过也不是绝对安全的.另外,服务器对Https的配置相对有点复杂,还需要到CA申请证书,而且一般还是收费的.而且Https的效率也比较低.一般,只有安全级别比较高的系统才会采用Https,比如银行等.而大部分安全级别要求不高的App还是采用http.

2.给每个接口都添加签名:给客户端分配一个密钥,每次请求接口时,将密钥和所有参数组合成源串,根据签名算法生成签名值,发送时将签名一起发送给服务器端验证.类似的可以参考OAuth1.0的签名算法.这样,就算拦截了登录几口,黑客也没有密钥,不知道签名算法,后续也无法操作.不过因为签名算法比较麻烦,而且容易出错,只适合对内的接口.如果你们的接口属于对外开放的API,那么就不太适合这种了,建议用OAth2.0的认证机制.
我们也给每个端分配一个appKey，比如Android、iOS、微信三端，每个端分别分配一个appKey和一个密钥。没有传appKey的请求将报错，传错了appKey的请求也将报错。这样，安全性方面又加多了一层防御，同时也方便对不同端做一些不同的处理策略。

另外，现在越来越多App取消了密码登录，而采用手机号+短信验证码的登录方式，我在当前的项目中也采用了这种登录方式。这种登录方式有几种好处：

1.不需要注册，不需要修改密码，也不需要因为忘记密码而重置密码的操作了；
2.用户不再需要记住密码了，也不怕密码泄露的问题了；
3.相对于密码登录其安全性明显提高了。

接口数据的设计:

接口的数据一般都采用JSON格式进行传输，不过，需要注意的是，JSON的值只有六种数据类型：

• Number：整数或浮点数
• String：字符串
• Boolean：true 或 false
• Array：数组包含着方括号[]中
• Object：对象包含在大括号{}中
• Null：空类型

所以，传输的数据类型不能超过这六种数据类型。以前，我们曾经试过传输Date类型，它会转为类似于”2016年1月7日 09时17分42秒 GMT+08:00”这样的字符串，这在转换时会产生问题，不同的解析库解析方式可能不同，有的可能会转乱，有的可能直接异常了。要避免出错，必须做特殊处理，自己手动去做解析。为了根除这种问题，最好的解决方案是用毫秒数表示日期。
另外，以前的项目中还出现过字符串的”true”和”false”，或者字符串的数字，甚至还出现过字符串的”null”，导致解析错误，尤其是”null”，导致App奔溃，后来查了好久才查出来是该问题导致的。这都是因为服务端对数据没处理好，导致有些数据转为了字符串。所以，在客户端，也不能完全信任服务端传回的数据都是对的，需要对所有异常情况都做相应处理。
服务器返回的数据结构，一般为：

{code：0msg: "success"data: { key1: value1, key2: value2, ... }}

• code: 状态码，0表示成功，非0表示各种不同的错误
• msg: 描述信息，成功时为”success”，错误时则是错误信息
• data: 成功时返回的数据，类型为对象或数据

不同错误需要定义不同的状态码，属于客户端的错误和服务端的错误也要区分，比如1XX表示客户端的错误，2XX表示服务端的错误。这里举几个例子：

• 0：成功
• 100：请求错误
• 101：缺少appKey
• 102：缺少签名
• 103：缺少参数
• 200：服务器出错
• 201：服务不可用
• 202：服务器正在重启

错误信息一般有两种用途：一是客户端开发人员调试时看具体是什么错误；二是作为App错误提示直接展示给用户看。主要还是作为App错误提示，直接展示给用户看的。所以，大部分都是简短的提示信息。

data字段只在请求成功时才会有数据返回的。数据类型限定为对象或数组，当请求需要的数据为单个对象时则传回对象，当请求需要的数据是列表时，则为某个对象的数组。这里需要注意的就是，不要将data传入字符串或数字，即使请求需要的数据只有一个，比如token，那返回的data应该为：

// 正确data: { token: 123456 }// 错误data: 123456

接口版本的设计:

接口不可能一成不变，在不停迭代中，总会发生变化。接口的变化一般会有几种：

• 数据的变化，比如增加了旧版本不支持的数据类型
• 参数的变化，比如新增了参数
• 接口的废弃，不再使用该接口了

为了适应这些变化，必须得做接口版本的设计。实现上，一般有两种做法：

• 每个接口有各自的版本，一般为接口添加个version的参数。
• 整个接口系统有统一的版本，一般在URL中添加版本号，比如http://api.domain.com/v2。

大部分情况下会采用第一种方式，当某一个接口有变动时，在这个接口上叠加版本号，并兼容旧版本。App的新版本开发传参时则将传入新版本的version。
如果整个接口系统的根基都发生变动的话，比如微博API，从OAuth1.0升级到OAuth2.0，整个API都进行了升级。
有时候，一个接口的变动还会影响到其他接口，但做的时候不一定能发现。因此，最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。

转载自 : http://www.cnblogs.com/zhouguowei/p/5264775.html

• 学习了!感谢作者.