接口书写注意事项
1.文档要写周全,需要的每个字段,规定是什么类型,什么含义要标柱清楚,写完接口后自己先测试一下是否通过,不要直接扔给测试或者开发,然后反应错误了在进行修改
2. 接口要做到小,同时比较多,切记一个接口的代码量很多。做到接口要小而多,不要做大而全,以方便减少服务器的压力
3. 在做app接口的返回值的数据类型时需要注意,弱语言和强语言的处理数据类型毕竟不同,比如空数组的返回至少要初始化一个,这样可以让一些客户端处理起来方便,而不会因为一些数据的不正常造成 crash,还有就是错误返回的标准统一周全,以及返回适当的错误提示
4. 当数据库里的字段发生变更时,要及时更新文档,并和使用到的程序员和测试人员说一声
5.接口的测试(如果是Node.Js / MongoDB 的搭配,也可以弄个自动化测试),测试要包含所有的返回情况,接口的规范,可以遵循 RESTfull API
6.还有个需要注意的,可能是 content-type ,返回的是 json 数据,最好就是 application/json ,客户端一般都会用第三方的网络请求组件,而一些组件对 content-type 有严格的限制,当然这个需要和客户端的程序员确认,避免你明明返回 json 在 text 下可以正常显示,客户端却无法解析出来
7.我们的接口一般是给app用的, 接口要加密。每次回话前 都向服务器请求token,服务器以session存储,回话结束,就销毁
8. 用restful,最好开启https,不然会被坑死的,运营商,浏览器,路由器一般发现4XX,5XX状态,喜欢替换成自己的广告,如果不用restful,返回的都是200状态,就不会被替换成运营商或路由器自己的导航页了,运营商,路由器容易擅自根据403,404状态推自己的导航页
常见的问题
如果服务端采取了防重放机制,要求http请求带上时间戳,和服务器的时间误差超过一段距离则请求不合法。那么,客户端的时间戳不一定是正确的(有可能用户改了系统时间),这种方案该怎么调整?
(1)第一次启动从服务器获取一次时间,之后客户端自动计数维护这个时间,每秒加一,这样就跟服务器时间一致了
(2):应该是需要时间戳的请求。带上服务器的时间戳。比如说修改个人资料。是请求个人资料。客户端修改。发送修改后的个人资料。在请求个人资料的时候服务器就带上时间戳。最好是上面所说的token。我们可以验证这个时间戳。发送的时候带上这个时间戳或者token
关于session:
APP登录没有了网页的session,怎么处理的?
1、jwt oauth - slee
2、app一般通过token来进行登录验证
3、就是登录返回APP一个token,保存在客户端,下次传递这个token来验证身份
一次请求算一个会话?还是token是有时效的?
1、token是有时效的,可以去更新-蜗牛
2、token 不保存到客户端本地。 - windk
每次请求前必须过去一次?
1、对,时效时间内,多次请求 可以只取一次 - windk
2、token这个属于安全性的东西 取决于信息的重要性 通常来说安全性要求越高,所要做的活就越,我们大致换了经历过三种方面:
第一种 直接在 header里传用户名 密码 最简单,但最不安全。
第二种 就在客户端种cookie 这个跟web一样了。
第三种 就是用token 用一定的规则生成token 客户端每次请求带token 服务端用同一规则生成token 把token有效时间 放到token加密规则里 省得再验证一个时间戳