App架构设计经验谈:接口的设计

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

安全机制的设计

现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:

  1. 用户用密码登录成功后,服务器返回token给客户端;

  2. 客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;

  3. 服务器检查token的有效性,有效则返回数据,若无效,分两种情况:

    • token错误,这时需要用户重新登录,获取正确的token

    • token过期,这时客户端需要再发起一次认证请求,获取新的token

然而,此种验证方式存在一个安全性问题:当登录接口被劫持时,黑客就获取到了用户密码和token,后续则可以对该用户做任何事情了。用户只有修改密码才能夺回控制权。

如何优化呢?第一种解决方案是采用HTTPS。HTTPS在HTTP的基础上添加了SSL安全协议,自动对数据进行了压缩加密,在一定程序可以防止 监听、防止劫持、防止重发,安全性可以提高很多。不过,SSL也不是绝对安全的,也存在被劫持的可能。另外,服务器对HTTPS的配置相对有点复杂,还需 要到CA申请证书,而且一般还是收费的。而且,HTTPS效率也比较低。一般,只有安全要求比较高的系统才会采用HTTPS,比如银行。而大部分对安全要 求没那么高的App还是采用HTTP的方式。

我们目前的做法是给每个接口都添加签名。给客户端分配一个密钥,每次请求接口时,将密钥和所有参数组合成源串,根据签名算法生成签名值,发送请求时 将签名一起发送给服务器验证。类似的实现可参考OAuth1.0的签名算法。这样,黑客不知道密钥,不知道签名算法,就算拦截到登录接口,后续请求也无法 成功操作。不过,因为签名算法比较麻烦,而且容易出错,只适合对内的接口。如果你们的接口属于开放的API,则不太适合这种签名认证的方式了,建议还是使 用OAuth2.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:
     message: "success"
     data: { key1: value1, key2: value2, ... }
 } 
  • code: 状态码,0表示成功,非0表示各种不同的错误

  • message: 描述信息,成功时为”success”,错误时则是错误信息

  • data: 成功时返回的数据,类型为对象或数据

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

  • 0:成功

  • 100:请求错误

  • 101:缺少appKey

  • 102:缺少签名

  • 103:缺少参数

  • 200:服务器出错

  • 201:服务不可用

  • 202:服务器正在重启

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

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

// 正确
data: { token: 123456 }

// 错误
data: 123456

接口版本的设计

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

  • 数据的变化,比如增加了旧版本不支持的数据类型

  • 参数的变化,比如新增了参数

  • 接口的废弃,不再使用该接口了

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

  1. 每个接口有各自的版本,一般为接口添加个version的参数。

  2. 整个接口系统有统一的版本,一般在URL中添加版本号,比如http://api.domain.com/v2。

大部分情况下会采用第一种方式,当某一个接口有变动时,在这个接口上叠加版本号,并兼容旧版本。App的新版本开发传参时则将传入新版本的version。

如果整个接口系统的根基都发生变动的话,比如微博API,从OAuth1.0升级到OAuth2.0,整个API都进行了升级。

有时候,一个接口的变动还会影响到其他接口,但做的时候不一定能发现。因此,最好还要有一套完善的测试机制保证每次接口变更都能测试到所有相关层面。

写在最后

关于接口设计,暂时想到的就这么多了。各位看官看完觉得有遗漏或有哪些需要优化的欢迎提出一起讨论。

原文转自: 51CTO. 版权归原作者所有.

Lionden 2016年03月24日

E-mail:hsdlionden@hotmail.com

转载请注明原文地址和博客园Liondenhttp://www.cnblogs.com/lionden/

【转】App架构设计经验谈:接口的设计的更多相关文章

  1. 【转】 App架构设计经验谈:接口的设计

    App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的 ...

  2. App架构设计经验谈:接口的设计

    App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的 ...

  3. 转: ios app架构设计

    http://keeganlee.me/post/architecture/20160107 看完这一系列文章后就知道怎么回答这类问题了: App架构设计经验谈:接口的设计 App架构设计经验谈:技术 ...

  4. App架构设计经验谈:服务端接口的设计

    App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉. 安全机制的设计 现在,大部分App的接口都采用RESTful架构,RESTFul最重要的 ...

  5. App架构设计学习(一)---- 接口的设计

    一.哎,最近换了家工作,结果工作很出的我意外,没有干熟悉的根据需求写代码,反而让我一个小菜鸟去重构一下App的架构(他们公司的app,已经上线了1.0版本了),没办法,只有硬着头皮去先学习学习,再总结 ...

  6. Hybrid APP 架构设计思路

    关于Hybrid模式开发app的好处,网络上已有很多文章阐述了,这里不展开. 本文将从以下几个方面阐述Hybrid app架构设计的一些经验和思考. 原文及讨论请到 github issue 通讯 作 ...

  7. 2014年的Google I/O app设计中的材料设计-渣渣的翻译

    又是一篇翻译,用了三个多小时.http://android-developers.blogspot.co.id/2014/08/material-design-in-2014-google-io-ap ...

  8. Windows Server基础架构云参考架构:硬件之上的设计

    作者 王枫 发布于2014年1月27日 综述 毫无疑问,移动互联网.社交网络.大数据和云计算已经成为IT发展的四个大的趋势.其中云计算又为前三个提供了一个理想的平台.今天不仅互联网公司,很多传统行业的 ...

  9. 组件接口(API)设计指南-文件夹

    组件接口(API)设计指南-文件夹 组件接口(API)设计指南[1]-要考虑的问题 组件接口(API)设计指南[2]-类接口(class interface) 组件接口(API)设计指南[3]-托付( ...

随机推荐

  1. JS仿淘宝星星评价

    //直接复制过去就可以了(你也可以吧css和js封装成css和js文件导入). <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transit ...

  2. 转载ali面

    引言 首先声明,不要再问LZ谁是林萧,林萧就是某著名程序员小说的主角名字. 写这篇文章的目的其实很简单,算是对之前LZ一篇文章的补充和完善. 之前LZ写过一篇<回答阿里社招面试如何准备,顺便谈谈 ...

  3. UITableView中的cell的优化

    1.cell的重用 所谓的cell的重用就是,视图加载的时候只会创建当前视图中的cell,或者比当前视图多一点的cell, 当视图滚动的时候,滚出屏幕的cell会放进缓存中,滚进屏幕的cell会根据I ...

  4. 洛谷 P1092 虫食算 Label:dfs

    题目描述 所谓虫食算,就是原先的算式中有一部分被虫子啃掉了,需要我们根据剩下的数字来判定被啃掉的字母.来看一个简单的例子: 43#9865#045 +8468#6633 44445509678 其中# ...

  5. iframe自适应高度js

    <iframe src="http://www.fufuok.com/" id="iframepage" name="iframepage&qu ...

  6. Java中BigDecimal的8种舍入模式

    java.math.BigDecimal 不可变的.任意精度的有符号十进制数.BigDecimal 由任意精度的整数非标度值和32位的整数标度(scale)组成. 如果为零或正数,则标度是小数点后的位 ...

  7. Hadoop源码之Configuration

    本文hadoop版本为最新版本2.6.Configuration做为Hadoop的一个基础功能承担着重要的责任,为Yarn.HSFS.MapReduce.NFS.调度器等提供参数的配置.配置文件的分布 ...

  8. 不自动生成Android Dependencies的解决方式

    今天遇到的奇怪问题是网上下载的demo导入第三方包运行后Android: NoClassDefFoundError的错误,原因是第三方的jar包并没有打包进apk里,运行是肯定要出错的. 网上百度了N ...

  9. (转载)ios关闭虚拟键盘的几种方法

    在iOS应用开发中,有三类视图对象会打开虚拟键盘,进行输入操作,但如何关闭虚拟键盘,却没有提供自动化的方法.这个需要我们自己去实现.这三类视图对象分别是UITextField,UITextView和U ...

  10. WPF button 如何区分click和doubleclick

    WPF button 同时处理两个事件时候会先触发click事件,触发doubleclick事件  ,那如何区分呢,可以这样设置: private static DispatcherTimer myC ...