API接口设计 注意问题
摘要: 总结一下API接口开发过程中的注意事项 1、跨平台性 所谓跨平台是指我们的接口要能够支持不同的终端,比如Android、iOS、windowsphone以及桌面软件、网站等。如:不同的终端每页显示的记录数不同 采用通用的解决方案,比如通信协议就采用最常用的HTTP协议,如果是即时通信,可以采用开放的XMPP协议,做游戏的可以采用可靠的TCP协议,除非TCP不够用了,再采用定制的UDP协议。
总结一下API接口开发过程中的注意事项
1、跨平台性
所谓跨平台是指我们的接口要能够支持不同的终端,比如Android、iOS、windowsphone以及桌面软件、网站等。如:不同的终端每页显示的记录数不同
采用通用的解决方案,比如通信协议就采用最常用的HTTP协议,如果是即时通信,可以采用开放的XMPP协议,做游戏的可以采用可靠的TCP协议,除非TCP不够用了,再采用定制的UDP协议。
数据交换采用xml或者json格式或者webservice等等。总之,要达到的目标就是让不同的端能够很方便的使用你的接口。
2、良好的响应速度
接口应该以最快的速度将数据返回给请求者,要达到的目标就是快,一个页面,秒开最好,超过三秒就需要找找原因了。数据量按需分配,APP客户端需要什么数据就返回什么数据,过多的数据量影响处理速度,最重要的是影响传输效率
3、接口要为移动客户端考虑
比如,在移动端里,下拉刷新和上拉加载更多是很常见的功能,如果接口仍然按照传统的web思路,
只提供按页读取的话,就会造成移动端的额外的数据请求和计算。 这时,接口就应该针对这两种类型的操作提供额外的支持。
4、考虑移动端的网络情况和耗电量
如果让我们说出哪类app比较好,可能还不大好说,但是如果让我们说出哪些app很差,我们肯定会说出那些体积很大、占用内存多、界面很卡、费电的app 不好。对于网络情况,接口应该具备为不同的网络提供不同的内容的能力如果我们能够知道用户的网络情况,只有在wifi的情况下才给用户传输封面图、缩略图 之类的,
是不是可以帮用户节省很多流量呢
5、通用的数据交换格式
目前,对于接口和客户端的数据交换格式,基本上就是三种,xml和json和webservice,而现在使用json的应该占大多数最麻烦的就是处理Date类型,因为JSON本身没有Date类型,因此,JSON库将Date类型的数据序列化时会转为String。这时,不同环境, 不同平台,以及用不同的JSON解析库,转换后的结果经常会不同。比如,你在开发机上可能得到的结果是”2016-1-1 17:11:11”,但放到服务器后结果却变成了“Jan 1,2016 5:11:11 PM” ,客户端进行反序列化时无疑会失败。后来,我取消了所有Date类型,统一采用时间戳表示,就再没有转化的烦恼了。 另外,接口的开发人员有时候会将一些数据错误地转换为了String,导致客户端使用时因类型错误而异常。例如,本来是数字的1,被转成 了"1",客户端做运算时就会出错,或用switch判断时也会出错,或其他无法转换的情况发生时;例如,为空时JSON正确地表示应该是null,但如 果转为了String就变成了"null",那问题就来了,我遇到的因为这个错误的转换导致的程序奔溃已经好几次了,第一次的时候,查了一整天才定位到问题所在
6、接口统计功能
在做PC端网站的时候,我们都会给我们的网站加上个统计功能,要么自己写统计系统,要么使用第三方的比如GA
移 动端接口API则需要我们自己实现统计功能,这时就需要我们尽可能多的收集客户端的信息,除了传统的IP、User-Agent之外,还应该收集一些移动 相关的信息,比如手机操作系统,是android还是ios,都是什么版本,用户使用的网络状况,是2G、3G、4G还是WIFI。客户端APP是什么版 本信息。
7、客户端与服务端的肥瘦平衡
在移动开发中,由于客户端的修改会很费时费力,特 别是IOS应用还要经过Apple审核,另外,当前IOS开发人员、Android开发人员的人工成本普遍较高,人才紧缺,基于这两点,能在服务器端实现 的功能就不要放在客户端,毕竟服务器端程序的修改要比客户端方便、灵活、快捷的多。
8、隐式用户与显式用户
显式用户指的是,APP程序中有用户系统,一个username、password正确的合法用户,称之为显式的用户,
通常显式用户都需要注册,登录以后能完成一些个人相关的操作。
隐式用户指的是,APP程序本身就没有用户系统,或者一个在没有登录的情况下,使用我们APP的用户。
在这种情况下,可以通过客户端生成的UDID来标识一个用户。
有了用户信息,我们就能够了解不同用户的使用习惯,而不仅仅是全体用户的一个整体的统计信息,
有了这些个体的信息之后,就可以做一些用户分群、个性化推荐之类的事情。
9、安全问题
设计API第一个需要考虑的是API的安全机制。我负责的上一个项目,因为API的安全问题,就被人攻击了两次。之后经过分析,主要存在两个漏洞: 一是因 为缺少对调用者进行安全验证的方式,二是因为数据传输不够安全。那么,制定API的安全机制,主要就是为了解决这两个问题:
- 保证API的调用者是经过自己授权的App;
- 保证数据传输的安全。
第一个问题的解决方案,我主要采用设计签名的方式。对每个客户端分别分配一个AppKey和AppSecret。需要调用API时,将AppKey加入请求参数列表,并将AppSecret和所有参数一起,根据某种签名算法生成一个签名字符串,然后调用API时把该签名字符串也一起带上。服务端收到请求之后,根据请求中的AppKey查询相应的AppSecret,按照同样的签名算法,也生成一个签名字符串,当服务端生成的签名和请求带过来的签名一致的时候,那就表示这个请求的调用者是经过自己授权的,证明这个请求是安全的。而且,每个端都有一个Key,也方便不同端的标识和统计。为了防止AppSecret被别人获取,这个AppSecret一般写死在代码里面。另外,签名算法也需要有一定的复杂度,不能轻易被别人破解,最好是采用自己规 定的一套签名算法,而不是采用外部公开的签名算法。另外,在参数列表中再加入一个时间戳,还可以防止部分重放攻击。
接口不能直接调用OAuth认证(rsa加密),ip白名单
接口的安全工作不能马虎,暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,
如果数据特别敏感,可以考虑采用SSL/TLS等加密传输,或者客户端、服务器端约定一个加密算法和密钥,对来往传输的数据进行加密、解密。如将所有参数加签名算法得到一个签名验证参数signhttp://hudeyong926.iteye.com/blog/2287954
表单类接口防止重复提交:调用过的接口sign存起来,检查sign是否存在
10、良好的接口说明文档和测试程序
接口文档要清晰、明了,包含多少个接口,每个接口的地址、参数、请求方式、数据交换格式、参数是否必填、编码格式UTF8,返回值等都要写清楚。
接口测试程序,有条件的话,也可以提供,方便前后端的调试
11、版本的维护
随着业务的变化,客户端APP和服务器端API都会发生变化,增加新的功能,修改已有的功能,
增加功能还好说, 如果是接口需要修改,那么就面临着同一个接口要同时为不同版本的客户端服务的问题。
因此,服务器端接口也要做好相应的版本维护。
主版本更新可以把版本号放入API的URL中/api-v2来指出所使用的API版本
次要版本的修改是通过客户在API调用时发起请求的HTTP头部做指定的头部的版本元素看起来是这样的:
Element-Version: 1
12、接口数据、状态
接口必须提供明确的数据状态信息,不管是成功的,还是失败的,都必须返回给APP客户端。
13、接口、参数命名准确。
无论是接口还是参数,命名都应该有意义,让人一目了然。接口调试技巧前提必须放在外网上
1》服务端return 调试信息,客户端调用并显示结果,
2》在服务端将结果保存成文件在打开文件查看,即日志型调试(或建临时表放在数据库表里)
考虑突然断网或接口信息返回超时异常情况的业务处理(先扣金额更新状态,如有问题自动返回)
支付宝
- <span style="font-size: 14px;">$alipaySubmit = new AlipaySubmit($alipay_config);
- $url = $alipaySubmit->alipay_gateway_new.$alipaySubmit->buildRequestParaToString($parameter);
- header("Location: {$url}");</span>
来源:http://blog.csdn.net/xiao_tommy/article/details/54864920
API接口设计 注意问题相关推荐
- API接口设计之RESTful软件架构风格
说到API接口设计有的喜欢用Web Service,有的喜欢用WCF,当然也有还在用最原始的ashx,aspx页面的.无论采用什么方式能很好的满足业务需求就ok,但是不同的方式在扩展性.易用性,可维护 ...
- 16. 设计模式之契约原则:如何做好 API 接口设计?
一.契约式设计原则:API 设计的指导书 无论是架构设计还是编码实现,现在都越来越离不开接口设计,接口可以说是新时代的"集装箱",是得到了几乎所有人一致共识的通用标准. GoF 在 ...
- API接口设计,需要注意这4点
原文 | http://www.woshipm.com/pd/2772820.html 原则上API接口设计一般出现在开发的详细设计中,但是随着诸多公司建立开放平台,产品经理也逐渐需要能理解API接口 ...
- API接口设计最佳实践
目录 目录 前言 API接口设计 Token设计 API接口设计原则 1.明确协议规范 2.统一接口路径规范 3.统一接口版本管理 4.为你的接口设定调用门槛 5.接口返回规范 6.接口安全规范 7. ...
- 优秀的API接口设计原则及方法
一旦API发生变化,就可能对相关的调用者带来巨大的代价,用户需要排查所有调用的代码,需要调整所有与之相关的部分,这些工作对他们来说都是额外的.如果辛辛苦苦完成这些以后,还发现了相关的bug,那对用户的 ...
- API 接口设计中 Token 类型的分类与设计
在实际的网站设计中我们经常会遇到用户数据的验证和加密的问题,如果实现单点,如果保证数据准确,如何放着重放,如何防止CSRF等等 其中,在所有的服务设计中,都不可避免的涉及到Token的设计. 目前,基 ...
- api接口设计相关总结
写过不少接口,不过一直没有去总结,网上搜了一下,大同小异,此文根据以下几个链接整理修改: https://segmentfault.com/a/1190000004051246 http://blog ...
- php后台对接ios,安卓,API接口设计和实践完全攻略,涨薪必备技能
2016年12月29日13:45:27 关于接口设计要说的东西很多,可能写一个系列都可以,vsd图都得画很多张,但是由于个人时间和精力有限,所有有些东西后面再补充 说道接口设计第一反应就是restf ...
- API接口设计要考虑的几个重要原则和方法总结
转载:https://ask.zkbhj.com/?/article/254 2020博客地址汇总 2019年博客汇总 这里想和大家讨论的是在后台接口设计过程中,还有哪些方面需要考虑,以及还有哪些优秀 ...
最新文章
- 一个网站让你系统的入门脑机接口和神经科学
- Linux 被***后的检查
- c语言多种选,教你轻松学会C语言系列之——一种更简洁、更经典的选择结构
- Luogu 1019 单词接龙
- Windows下自动备份Oracle数据库
- ProgressBar进度条使用注解
- Session操作对象的三种状态
- opencv怎么安装?opencv下载安装教程
- PDF 文件如何转换从可以编辑的文本和word
- 网课题库系统公众号功能
- vue修饰符——.lazy
- 2019 年技术大趋势预测
- iOS APP 上架审核过程中常见问题整理
- 足以代替Apache的Nginx
- 新手nvm npm 卸载不用依赖包,项识别为 cmdlet、函数、脚本文件,等命令集合
- 柯尼卡美能达打印机无法使用ID打印
- 手把手教你使用R语言做LASSO 回归
- 2021年CS保研经历(一):北邮CS夏令营、北师大AI夏令营、天津大学CS夏令营
- 工业自动化控制系统中的PLC模拟量信号数据采集如何实现?
- BZOJ 1193 HNOI2006 马步距离
热门文章
- vscode只有utf8_基于VSCode搭建LaTeX写作环境
- 03_ClickHouse数据格式,TabSeparated、TSKV、CSV格式、JSON格式、Parquet、ORC、其它数据格式(Native,Pretty,Values,Vertical等)
- RocketMQ特性、专业术语(Producer,Producer Group,Consumer Group,Topic,Message,Tag,Broker,Name Server)等
- HDFS命令行客户端使用,命令行客户端支持的命令参数,常用命令参数介绍
- linux下重启weblogic(关闭和启动)
- Eclipse Memory Analyzer以及内存泄露的原因
- Oracle基本查询
- chrome插件infinity_5款超好用Chrome插件,快试试看!
- Linux设备驱动之I/O端口与I/O内存
- OAuth2.0授权码模式学习