APP架构之后端接口设计方案
来源:广州软件开发 编辑:广州软件开发公司 日期:2020-05-13
1 规划思维
APP对服务器端要求是比较严厉的,在移动端有限的带宽条件下,要求接口响应速度要快,一切在开发过程中尽量挑选功率高的结构,对数据要求也比较严厉,app需求什么数据就传什么数据,不可多传,过多的数据量影响处理速度,最重要的是影响传输功率。接口要标准,以面向目标的思维规划接口。
2 app后端和java web后端的差异
由于之前开发过安卓,现在也在开发java web 后端,所以这儿总结一下。发现有的做java web 后端的同学并不太清楚。
其实关于后台开发来说原理都差不多。只不过app的后台开发和web不一样的地方在于传输数据格式不一样,一般来说web拜访后回来的是一个html页面,少部分是json格式;而一般app的后台开发大部分直接传json格式数据(也有不是json格式的,看项目的挑选,但一般来说都是json),少部分会直接回来html5的页面。
还有一个不同点在于登录验证和数据加密,一般web是运用session验证登录状况,而app则运用token来验证登录状况(token是自己定义的一个和用户ID相关的加密字符串,传入后台后从数据库查询用户信息)。还有假如对安全性要求较高,app传输数据时或许会对数据进行加密,而web一般没有这一步,web的加密一般是运用https。
至于说android和ios的开发环境不一样那是指的app开发,和后台无关。app的后台和java web的后台没有本质差异。app的一个后台能够即提供给android,也能够一同提供给iOS,它便是把app提交的数据处理后刺进数据库和从数据库查出数据处理后传给app。
3 安全机制的规划
3.1 服务端token方法-相似session
现在,大部分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的恳求也将报错。这样,安全性方面又加多了一层防护,一同也便利对不同端做一些不同的处理战略。
3.2 客户端token方法
客户端生成token传给服务端校验,一致就经过用户验证。
经过时刻戳+用户仅有标识+MD5加密=token(算法自定义),而且把时刻戳传给后台,后台通 过后台体系的时刻戳和客户端传过去的时刻戳能够规定当时用户在1分钟内这次接口能够正常运用,也便是 说,当黑客从路由获取到衔接后,只要1分钟的时刻能够运用这次接口(时刻后台能够自定义),这样很大程度 上确保了接口的安全性,一同,这种方法也能够有用的解决用户登入过期,也便是运用session的方法的缺乏,但是有个问题,假如客户端和服务端体系时刻不一致,就不能这样用了,所以这个时刻戳怎么获取,也是一个关键点,或许经过接口从后台接口获取,也能够运用其他方法,有好的主张能够一同探讨
3.3 手机验证码登陆
现在越来越多App取消了暗码登录,而选用手机号+短信验证码的登录方法,我在当时的项目中也选用了这种登录方法。这种登录方法有几种优点:
不需求注册,不需求修正暗码,也不需求由于忘掉暗码而重置暗码的操作了;
用户不再需求记住暗码了,也不怕暗码泄露的问题了;
相关于暗码登录其安全性显着提高了。
4 接口数据的规划
接口的数据一般都选用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:0, 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
常用的HTTP状况码有:
200 OK 201 Created 204 No Content 304 Not Modified 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 405 Method Not Allowed 410 Gone 415 Unsupported Media Type 422 Unprocessable Entity 429 Too Many Requests 500 Internal Server Error 503 Service Unavailable
5 接口版别的规划
接口不或许永久不变,它会跟着需求的改变而做出相应的变化。接口的改变一般会有几种:
数据的改变,比方增加了旧版别不支持的数据类型
参数的改变,比方新增了参数
接口的废弃,不再运用该接口了
为了习惯这些改变,有必要得做接口版别的规划。完成上,一般有两种做法:
每个接口有各自的版别,一般为接口添加个version的参数。
整个接口体系有统一的版别,一般在URL中添加版别号,比方http://api.demo.com/v2。
大部分情况下会选用第一种方法,当某一个接口有变化时,在这个接口上叠加版别号,并兼容旧版别。App的新版别开发传参时则将传入新版别的version。
假如整个接口体系的根基都发生变化的话,比方微博API,从OAuth1.0升级到OAuth2.0,整个API都进行了升级。
有时候,一个接口的变化还会影响到其他接口,但做的时候不必定能发现。因此,最好还要有一套完善的测验机制保证每次接口变更都能测验到一切相关层面。
6 编撰接口文档
文档先行。
好的文档,和洽的接口同样重要。接口文档需求被很简单地找到和拜访。大部分开发者会在进行接口开发之前,检查并检查接口文档。假如这些接口文档是写在PDF文档里,或许需求登录才干检查,那将不仅仅是难于查找,还不利于查找。
接口文档应该描绘完整的 Request/Response Cycle,并附上具体的比如。最好是,这些比如应该是真实能够拜访的,比方把链接复制到浏览器里履行,或许用curl履行。GitHub 和 Stripe 的接口文档都写得很不错。
一旦你发布了一个API,那意味着,在没有通知调用者的情况下,你有责任不去破坏该接口的已有功用。假如你在往后修正该接口,需求及时更新接口文档,而且在发布接口的更新之前,及时通知你的接口调用者。
相关阅读