>  기사  >  백엔드 개발  >  移动接口API服务/从零到一

移动接口API服务/从零到一

WBOY
WBOY원래의
2016-06-20 12:40:25912검색

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

也许你会说,现在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 及 htnlspecialchar进行过滤,基本也就够了!

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

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

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

欢迎批评,欢迎指正,欢迎提问!

성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.