recover517的博客

just look look

关于APP接口

在公司写app的接口也有一段日子了,从刚入公司完全不会写接口,一步步摸索,到现在有点小理解。对于接口,我也有了自己的一点点小心得,在这里也拿出来分享一下。

最初写接口,我只是将app端当做前端向服务端请求ajax一样的调用我们的接口,然而事实上也查不了多少,对于所期望的数据结构而言,他们是相似的,我们都是返回一个json数据,但是由于app大部分都是java和ios这种强类型语言,我们不得不把json格式中的所有参数全部转化为字符串,放置app崩溃。

现在为止的所有app接口,我都是基于thinkphp3.2框架写的,thinkphp自带的ajaxReturn能将我们的数据转化为json格式返回,但是却无法未我们进行格式处理,在这里,我更需要一个方法,在将我的数据转化为json之前,对数据进行字符串格式的强转,提高我的开发效率。所以,我自己写了一个ajaR的函数,在函数中,我调用了另一个递归函数,对数据进行格式的处理,将null转化为空字符串,将int类型或者float类型转化为字符串类型。而在实际接口开发过程中,我只需要将我组合好的数据放入这个函数即可,大大地提高了我的接口输出数据的可控性。

对于接口来说,另一个至关重要的事情就是保证接口的安全性,第一次开发接口的时候,我在写用户登录的时候,验证用户登录完毕之后便向app返回一个userid,app每次拿着userid去请求接口,起初的时候我并没有怎么注意,开发到后来我就明白了,userid是我作为表关键字段自增的整型,如果用户登录只是返回了一个userid,那么这个接口就没有安全性可言了,设想,userid是从1开始初级递增的,假设我不通过登录得到userid,在我获取到app的接口入口后,我还是能通过随意传一个整型的userid来模拟登录过任何一个用户,那么,用户的信息对于接口而言就是暴露的,没有安全性可言。于是在后期的开发中,我加入了token,app在登录后,我给app返回一个md5加密的字符串,用户app与接口交互的标识,同时,我将token存在表中,与userid进行关联,起到一个映射的作用,这样我就保证了用户在与app交互时候的安全性,当然,在token在数据传输的过程中被人截获的话,那已然是没有安全性可言的,但是相比较之前的userid而言,安全性已经得到了一个质的飞越。

在考虑完token的安全性后,我有开始考虑app的稳定性,即如何做到及时后台程序报错,也不影响程序的基本运行,数据总是基于数据库的,万一哪一天,数据库的某个字段发生改变,后端在查表的时候可能会一直报错,这样接口就会一直得到一个null的信息,导致app崩溃,而我的想法是,即使接口崩溃,app也不应该崩溃,而是应该出现一个友好的提示。于是我想到了为app接口做路由。

用框架的同学都知道,框架的好处就是单一入口,所有的访问都由同一个入口进入,方便我的一系列预定义操作等。基于这个想法,我也给我的app接口做了一个路由,所有的接口都经过我的一个叫api的module中过,我用__call的方法,为API的请求做路由,我觉得这样做有两个好处,1.当app访问一个不存在的接口的时候,并不会出现404的提示,而是可以由这个入口回复统一的信息,2.app接口可以有这个入口用try catch包裹,防止了接口报错时而引发的app崩溃。我现在的接口都是这么写的,目前写过来感觉还不错。

接口开发过程中任然有很多可以优化的地方,例如,我希望在开发过程中的提示语是具有专业性的提示,而生产环境中的提示则是人性化的,所以,对于ajaxR这个方法,我还需要做一个更好的升级,让他能同时适应生产环境和开发环境。

登录信息的安全性已经做到了,我有开始考虑接口地址的安全性,我不希望因为自己接口的url呈现的一定规则而然别人得到我接口的一些信息,我开始考虑在两端通信时,是否需要对接口进行安全性的统一算法的加密,因为我是单一入口的,也就很方便让自己统一解密加密信息并路由,目前还没有去实现这样的做法,总感觉这样的想法会派上用场。

写接口也已经4个多月了,公司并没有一个好的demo提供参考,以上都是自己慢慢摸索,的出来的一些心得,希望广大phper能借鉴一下,提出自己宝贵的意见或者建议。

阅读更多
版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/qq_31343581/article/details/60322706
文章标签: php
个人分类: php
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭