这篇就当是备忘录或以后开发 app 接口的规范参考吧。
1.关于加密
在抓包一些 app 之后,发现很多 app 对数据加密比较请示尤其是初创公司。如果没做好加密可能导致用户信息泄漏。
加密方式: MD5 、 RC4 、 RSA ,根据我们业务场景选择。
2.关于 app 版本
我们 app 一般一周一更新,部分功能也可能是热更新。 android 和 ios 的差异性。 有时候也要做好渠道和版本相关统计,运营或推广可能会用到。
3.关于 json 规范 如:
{ "error": false, //false 表示接口没有错误 true 表示请求异常 "data": { //服务器与客户端交互的数据
},
"message": "" //提示消息 如:参数错误
}
4.请求方式 get:选则 get 一般是把一些验证信息放到 http 请求的 head 中的 post:post 可以发送大量数据, php 的 post_max_size 默认值一般是 8MB,这时候验证信息可以放到 post 数据里面 5.开发文档 文档是服务器开发与客户端开发人员接口交流的重要途径,可能用 word/excel,或自己开发在线的文档 如: xx
1
airyland 2017-02-03 12:51:57 +08:00 via iPhone 2
md5 不是加密算法
|
2
Kilerd 2017-02-03 12:52:54 +08:00 via iPhone
MD5 , RC4 已经不安全
|
3
Sentur 2017-02-03 13:30:35 +08:00
我选择倒叙加密 #滑稽
|
4
CFO 2017-02-03 13:34:48 +08:00 via Android
get 请求是把信息放在 head 中的?谁告诉你的?
|
5
weiceshi 2017-02-03 13:45:08 +08:00
|
6
baiyi 2017-02-03 13:53:23 +08:00
"error": false
这一条不是多余吗 有错误返回错误,没错误不返不就好了 |
7
wuzhizhan 2017-02-03 14:34:30 +08:00
"error":false ,换成 retCode 之类的状态码更好些。
|
9
void1900 2017-02-03 15:31:48 +08:00
https
|
10
baiyi 2017-02-03 15:52:14 +08:00
@ragnaroks 唔...没接触过客户端开发,刚搜索了下实体对象,应该也可以在判断 HTTP status codes 为失败的时再创建,也就是说,成功是还是可以省略的
|
11
erming OP @baiyi 有时候并不是要返回错误,如:去获取一个商品时,由于某些原因商品 ID 没获取的,这时间我们返回一个提示性的数据“商品 ID 错误!”
实际项目的根据自己的需求来定格式就行了,这不是一个规范。 |
12
recall704 2017-02-03 17:28:29 +08:00 via iPhone
jwt
|
13
appstore001 2017-02-03 17:30:07 +08:00
每个开发者都需要这些东西,只是一般人想不了这么多,技术上也实现不了
|
14
erming OP @CFO
不是说 get 请求要把信息放在 head 中,是说有些信息可以放到 head 里面 如: app 版本是 1.0 的,在请求服务器接口时 head 中加入 App-Version: 1.0 这是我们的做法,对您只是一个建议。 |
16
baiyi 2017-02-03 17:34:23 +08:00
@erming 嗯,我只是觉得 api 的返回应该尽量减少必要的数据.
就比如说商品这个例子,我觉得错误时应该是返回: { "error":"该商品不存在" } 或者加一个`errorCode`: { "errorCode":"10086", "errorMessage":"该商品不存在" } 成功时就可以直接返回数据了啊: { "id":"1", "name":"x 商品" ...... } 而没有必要加上 `error=false` 或者是 `errorCode=0` 来表示成功: { "errorCode":"0", "id":"1", "name":"x 商品" ...... } 成功或失败的表示应该存在于 HTTP status codes |
19
hcymk2 2017-02-03 17:35:58 +08:00
又来了。 V2EX 能发投票贴么?
|
20
Kilerd 2017-02-03 17:44:39 +08:00 via iPhone
@erming 不懂为什么还要用这种能被破解的算法。顺便说下, RC4 已经能被破解了(不是遍历)。
有更好性能,更安全的算法不用,一定要等到被脱裤了才来哭,才来抱怨? |
21
erming OP |
22
annielong 2017-02-04 13:42:39 +08:00
看习惯了,还是喜欢先来一个统一的定义码,后面跟着信息
|
23
publicAdmin 2017-02-04 13:56:42 +08:00
@erming 请教下,关于产品迭代过程中后端和移动端的版本兼容你们是如何处理的呢?
|
24
erming OP @publicAdmin 后端接口以兼容为主,如果业务逻辑变化比较大,会新开接口
|
25
publicAdmin 2017-02-04 14:20:43 +08:00
@erming 针对业务逻辑变化较大的新开了接口后,用户 App 没更新至最新版(同时没法做热修复),是强更客户端还是后端部署 2 套代码靠路由来控制请求版本?
|
26
erming OP @publicAdmin 强制让用户更新体验不太好,我们规定在客户端请求接口时都要在 head 中加入版本号,如果接口有变化,服务端判断版本号后转发到对应接口上处理,客户端不需要做判断,这样做是因为一旦一个版本发布后更新是很困难的。
|
27
mingyun 2017-02-04 23:40:19 +08:00
jwt +1
|
28
chinvo 2017-02-05 11:40:27 +08:00
状态码我一般这样设计
Success: {"status": 0} Success with result: {"status": 1, "result":<object>} Faild: {"status": -n, message: "xxx"} 至于消息加密,个人认为 HTTPS 足矣。 |
29
jcuan 2017-02-06 00:03:50 +08:00 via Smartisan T1
以前我也用 true 和 false ,不过后来发现分辨错误还是不够用, errorMsg 也不是总能提示给用户的,而且总觉得这种提示信息由前端小伙伴控制比较好~~
还是用 errorCode 错误码比较棒。 最近刚用的: 0-没错误 1-9 服务器错误 10-99 前端参数错误 100-用户输入错误~~ |