API接口设计 注意问题

  • 时间:
  • 浏览:0

第五个疑问的防止方案,主要而是 采用 HTTPS了。HTTPS可能性加上了SSL安全协议,自动对请求数据进行了压缩加密,在一定多线程池池 还要能防止监听、防止劫持、防止重发,主要而是 防止顶端人攻击。而且,为了安全考虑,建议对SSL证书进行强校验,包括签名CA算是合法、域名算是匹配、是有的是自签名证书、证书算是过期等。

2》在服务端将结果保存成文件在打开文件查看,即日志型调试(或建临时表上放数据库表里

10、良好的接口说明文档和测试多线程池池

接口的安全工作非要马虎,暴力破解啊、SQL Injection啊、伪造请求和数据啊、重复提交啊也要考虑到,

8、隐式用户与显式用户

显式用户指的是,APP多线程池池 饱含用户系统,有另一个 username、password正确的合法用户,称之为显式的用户,

通常显式用户都时需注册,登录事先 能完成或多或少另一方相关的操作。

隐式用户指的是,APP多线程池池 并有的是就那末用户系统,可能性有另一个 在那末登录的状况下,使用或多或少人APP的用户。

在这一状况下,还要能通过客户端生成的UDID来标识有另一个 用户。

有了用户信息,或多或少人就要能了解不同用户的使用习惯,而不仅仅是全体用户的有另一个 整体的统计信息,

有了哪些地方地方个体的信息事先 ,就还要能做或多或少用户分群、个性化推荐累似 的事情。

Element-Version: 1

支付宝

接口应该以最快的时延单位将数据返回给请求者,要达到的目标而是 快,有另一个 页面,秒开最好,超过三秒就时需找找愿因了。数据量按需分配,APP客户端时需哪些地方数据就返回哪些地方数据,过多的数据量影响防止时延单位,最重要的是影响时延单位单位

9、安全疑问

次要版本的修改是通过客户在API调用时发起请求的HTTP头部做指定的头部的版本元素看起来是事先的:

主版本更新还要能把版本号上放API的URL中/api-v2来指出所使用的API版本

在移动开发中,可能性客户端的修改会很费时费力,特 别是IOS应用时需经过Apple审核,另外,当前IOS开发人员、Android开发人员的人工成本普遍较高,人才紧缺,基于这两点,能在服务器端实现 的功能就我过多 上放客户端,毕竟服务器端多线程池池 的修改要比客户端方便、灵活、快捷的多。

比如,在移动端里,下拉刷新和上拉加载更多是很常见的功能,可能性接口仍然按照传统的web思路,

只提供按页读取语句,就会造成移动端的额外的数据请求和计算。 这时,接口就应该针对这并有的是类型的操作提供额外的支持。

11、版本的维护

随着业务的变化,客户端APP和服务器端API都会处于变化,增加新的功能,修改已有的功能,

增加功能还好说, 可能性是接口时需修改,那末就面临着同有另一个 接口要一同为不同版本的客户端服务的疑问。

而且,服务器端接口也要做好相应的版本维护。

4、考虑移动端的网络状况和耗电量

可能性让或多或少人说出哪类app比较好,可能性还不大好说,而且可能性让或多或少人说出哪些地方app很差,或多或少人肯定会说出哪些地方地方体积很大、占用内存多、界面很卡、费电的app 不好。对于网络状况,接口应该具备为不同的网络提供不同的内容的能力可能性或多或少人要能知道用户的网络状况,非要在wifi的状况下才给用户传输封面图、缩略图 累似 的,

是有的是还要能帮用户节省而是 有流量呢

设计API第有另一个 时需考虑的是API的安全机制。我负责的上有另一个 项目,可能性API的安全疑问,就被人攻击了两次。事先 经过分析,主要处于有另一个 漏洞: 一是因 为缺少对调用者进行安全验证的措施,二是可能性数据传输处于问题安全。那末,制定API的安全机制,主要而是 为了防止这有另另一个 疑问:

12、接口数据、状况 接口时需提供明确的数据状况信息,不管是成功的,还是失败的,都时需返回给APP客户端。

表单类接口防止重复提交:调用过的接口sign存起来,检查sign算是处于

移 动端接口API则时需或多或少人另一方实现统计功能,这时就时需或多或少人尽可能性多的下发客户端的信息,除了传统的IP、User-Agent之外,还应该下发或多或少移动 相关的信息,比如手机操作系统,是android还是ios,有的是哪些地方版本,用户使用的网络状况,是2G、3G、4G还是WIFI。客户端APP是哪些地方版 本信息。

6、接口统计功能

3、接口要为移动客户端考虑

接口文档要清晰、明了,饱含多少个接口,每个接口的地址、参数、请求措施、数据交换格式、参数算是必填、编码格式UTF8,返回值等有的是写清楚

接口测试多线程池池 ,有条件语句,也还要能提供,方便前后端的调试

接口非要直接调用OAuth认证(rsa加密),ip白名单

1、跨平台性

可能性数据有点敏感,还要能考虑采用SSL/TLS等加密传输,可能性客户端、服务器端约定有另一个 加密算法和密钥,对来往传输的数据进行加密、解密。如将所有参数加签名算法得到有另一个 签名验证参数signhttp://hudeyong926.iteye.com/blog/2287954

13、接口、参数命名准确。 无论是接口还是参数,命名都应该有意义,让我一目了然。接口调试技巧前提时需上放外网上

1》服务端return 调试信息,客户端调用并显示结果,

总结一下API接口开发过程中的注意事项

考虑总爱断网或接口信息返回超时异常状况的业务防止(先扣金额更新状况,如有疑问自动返回)

2、良好的响应时延单位

 5、通用的数据交换格式

7、客户端与服务端的肥瘦平衡

第有另一个 疑问的防止方案,我主要采用设计签名的措施。对每个客户端分别分配有另一个 AppKey和AppSecret。时需调用API时,将AppKey加入请求参数列表,并将AppSecret和所有参数一同,根据并有的是签名算法生成有另一个 签名字符串,而且调用API时把该签名字符串也一同带上。服务端收到请求事先 ,根据请求中的AppKey查询相应的AppSecret,按照同样的签名算法,也生成有另一个 签名字符串,当服务端生成的签名和请求带过来的签名一致的事先 ,那就表示这一请求的调用者是经过另一方授权的,证明这一请求是安全的。而且,每个端有的是有另一个 Key,也方便不同端的标识和统计。为了防止AppSecret被别人获取,这一AppSecret一般写死在代码顶端。另外,签名算法也时需有一定的复杂度,非要轻易被别人破解,最好是采用另一方规 定的一套签名算法,而有的是采用实物公开的签名算法。另外,在参数列表中加上入有另一个 时间戳,还还要能防止次要重放攻击。

在做PC端网站的事先 ,或多或少人都会给或多或少人的网站加上个统计功能,要么另一方写统计系统,要么使用第三方的比如GA

所谓跨平台是指或多或少人的接口要要能支持不同的终端,比如Android、iOS、windowsphone以及桌面软件、网站等。如:不同的终端每页显示的记录数不同

目前,对于接口和客户端的数据交换格式,基本上而是 并有的是,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",那疑问就来了,我遇到的可能性这一错误的转换愿因的多线程池池 奔溃可能性好多少了,第一次的事先 ,查了一整天才定位到疑问所在

采用通用的防止方案,比如通信协议就采用最常用的HTTP协议,可能性是即时通信,还要能采用开放的XMPP协议,做游戏的还要能采用可靠的TCP协议,除非TCP处于问题用了,再采用定制的UDP协议。

数据交换采用xml可能性json格式可能性webservice等等。总之,要达到的目标而是 让不同的端要能很方便的使用你的接口。