怎样提供一个好的移动API接口服务/从零到一[开发篇]

　　引语：现在互联网那么热，你手里没几个APP都不好意思跟别人打招呼！但是，难道APP就是全能的神吗？答案是否定的，除了优雅的APP前端展示，其实核心还是服务器端。数据的保存、查询、消息的推送，无不是在服务器端完成的，默默地！那么，怎样提供一个好的服务端API接口就是一个至关重要的问题了！

　　也许你会说，现在APP这么泛滥，谁还不会写个服务端API接口程序啊？是的，也许，你是对的，但是本文想说明的和要讲的故事，是一个从零到一故事，是一个思想，是一个历程，一个可以推演的过程！

　　在给出答案之前，先抛几个问题，如果你自认为这些方面都做得很优秀，那么恭喜你，你已经是牛人了！请于文后留下你的箴言以供借鉴，多谢！如果你感觉还有待提高的，可以尝试在这里找找答案，不谢！（注：本人使用PHP语言进行开发，但这不重要）

　　1、采用什么样的服务器进行提供服务(也许不太准确)？如：soap server ?  yar server ? restful ? 好吧，我相信你肯定是用的restful风格的，因为这个才是王道！

　　2、怎样确定访问来路是正常的，或者说你怎样管理访问权限？（附：怎样获取传递过来的参数）

　　3、有加密方式吗？https ? 是否有区分不同场合？

　　4、怎样解决编码问题？

　　5、怎样控制接口版本迭代问题？

　　6、上传文件怎样处理？

　　7、怎样防止注入？（如果你也没有用框架）

　　8、怎样提升访问速度？怎样提高并发？

　　好，看完问题，让我们继续故事！

　　前编：公司是一个小公司，刚成立不久，技术人员也很少，几乎是一个人负责一个项目，如web前端，web后端，安卓端、IOS端。很明显，我的任务是，服务器端接口的提供！（那里的我，经验也是可怜的）

　　问题1、提供服务方式，之所以会想到用这几个东西提供服务，是因为，我用的就是PHP开发啊。PHP里就有这些东西，所以，很自然的嘛，soap,yar这两个东西在PHP与PHP程序之间的通信的确是不错的。但是，你要移动端对接，不止安卓，不止IOS。所以，只能国际化了呗！采用restful架构，其实说白了，也就是一个地址，就可以进行操作了，放心吧，大家都是这么干的，准没错！（附：请考虑提供接口只是进行数据的操作，倒底有没有必要去使用一个完整的MVC框架）

　　问题2、访问权限，为什么会有这个问题呢？如果是自己的网站，那么，你所访问的地址，就是你自己提供的，根本不需要什么访问权限控制！但是，如果对外提供服务，那就得考虑了。来访的人不是内部的怎么办？他登录了没有？现在有多少人在访问这个服务？这些东西，都应该被一目了然的呈现出来。那么，怎样控制来访人员呢？方法1、在程序里写死几个密码一类的东西，让客户端访问时，带上此变量以验证；方法2、为每个客户端（我说的是安卓或ios等一套源代码）提供一个appId,appKey，访问时携带，实际上，很多大公司都是这么干的；方法3、使用Oauth等授权方式。很明显，方法2是最好的方式，有了个这个东西，你也可以很方便的进行访问的有效记录！（实践：建立权限表，建立访问日志表，如有必要，建立模块访问权限表，错误描述表）

　　问题3、加密，一般提供接口我们都可以采用json方式（方便啊），那就是说，所有的访问，几乎都是采用明码传输，那么就必须有一定的假设信息被截获的防范措施（实际上，这个假设也很容易成立）！对于一般的信息，加一个普通的普通的签名即可，如：appId+appKey+访问参数+timestamp+随机字符n个 再 md5 得到签名，服务器端首先进行该签名验证，确认后，再进行后续操作！当然，对于支付一类的操作，这样的操作还是显得不够安全的，那就需要特殊对待，借助于https的加密，就安全多了！

　　问题4、编码问题，也许许多人看来，这并不是问题。但是我想说的是，PHP写代码真的很方便很随意，md5,json_encode等都语言自带的函数，但是对于java和swift可能就没那么简单了，还得自己去找别人封装的东西，有时稍有不对就可能导致签名不对，所有访问都无效！(这里主要说的是包含中文的地方)；我们当时大家采用的都是UTF8的编辑器开发，所以并没有什么太大问题！

　　问题5、版本迭代，这是个问题！因为，如果整个网站都是你的，你想怎么改都可以，反正别人访问也就只有你网址这一个入口。但是移动APP不一样了，每个人都是独立的，他们各自的版本都是不一样的。如果共用一套接口的话，小的改动还好，向后兼容就行了，但是对于一些大方向的改动，这将是致命的，要么强行使用户不能使用以促使其更新，要么你继续写一长篇无用的不可维护的冗余代码！所以，做好版本控制是必须的，主要实现为：传入一个version参数，从而调用不同的内部接口地址，当然，你可以直接接口地址指向另一目录！这样，就有很多个版本接口共存了！如 /pro/api/v1.0/xxx, /pro/api/v2.0/xxx

　　问题6、上传文件，这也是问题，因为，其他地方都是采用的文本内容传递至服务器，可以直接进行数据库保存操作，但是，对于上传文件则不一样。如果是网站，则一般只能使用Form表单进行提交，而且必须设置属性multipart/form-data,声明为文件类型。那也就是说，不能以普通的json格式提交了！解决方法有2个，方式1、先将文件以表单形式提交至服务器，服务器返回地址，再将地址组合进其他选项中，一起以json提交！方式2、整个内容以webForm表单形式提交，此类页面单独处理权限问题，并注意是否是伪造请求，可另加页面隐藏token验证！

　　问题7、防止注入，也许作为开发人员，说这个已经太low，但是我还是忍不住提了，因为，真的很重要，其实，接口要做的事情很简单，接受数据，保存数据，返回状态。所以，真心觉得，没必要去用一些很成熟的大型框架，太臃肿！那么注入问题，就只有你自己解决了。php 使用 mysql_real_escape_string 及 htmlspecialchar进行过滤，基本也就够了！

　　问题8、接口的访问速度，这个是很重要的。你有没有看到哪个APP访问速度很慢，大家还愿意用他的？做到秒开才是王道，由于各种验证，各种日志记录，已经消耗了不少时间，所以更要注意效率问题。索引、缓存、负载均衡、分布式，用起来。。。  哈哈，太宽泛了

　　从最初什么都没有，到最后，一整套接口的完成，大概花了一个多月时间，感觉还是有很多不OK的地方，再后来准备做消息推送，做长连接，结果由于某些原因，项目被中断，也就不了了之了。

　　写一点当时的过程，就当是一点点的收获吧。还记得，当初开始做的时候，参考资料实在太少，以至于做很多东西，都没有信心，只是凭感觉！！希望这篇文章能帮到部分处于这个时期的人！

　　其实不管是做什么样的开发，都应该是从核心要解决的问题出发的，当你把问题都解决了之后，也许，一个好的设计好的架构就已经悄然呈现！这也许就是解决问题之美吧！

　　欢迎批评，欢迎指正，欢迎提问！