关于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能借鉴一下，提出自己宝贵的意见或者建议。