Heim  >  Artikel  >  Backend-Entwicklung  >  移动接口API服务/从零到一

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

WBOY
WBOYOriginal
2016-06-20 12:40:25913Durchsuche

引语:现在互联网那么热,你手里没几个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的地方,再后来准备做消息推送,做长连接,结果由于某些原因,项目被中断,也就不了了之了。

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

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

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn