关于 app 接口开发

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2850 天前的主题，其中的信息可能已经有所发展或是发生改变。

这篇就当是备忘录或以后开发 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

转自： http://www.guodev.cn/archives/172

第 1 条附言 · 2017-02-03 17:52:23 +08:00

其实 app 接口开发涉及很多细节问题。
微信 /支付宝 /支付友盟统计消息推送（单人推送，群发，按标签推送，按版本推送等，有时候运营要知道到达率等等）
渠道统计，广告统计，针对单用户的各种统计。
包括客户端服务端异常监控等。
大家互相学习，不喜勿喷，谢谢！

App

加密

post

开发

30 条回复 • 2017-02-06 08:54:38 +08:00

airyland

2017-02-03 12:51:57 +08:00 via iPhone

md5 不是加密算法

Kilerd

2017-02-03 12:52:54 +08:00 via iPhone

MD5 ， RC4 已经不安全

Sentur

2017-02-03 13:30:35 +08:00

我选择倒叙加密 #滑稽

CFO

2017-02-03 13:34:48 +08:00 via Android

get 请求是把信息放在 head 中的？谁告诉你的？

weiceshi

2017-02-03 13:45:08 +08:00

@CFO
楼主是说：把一些验证信息放到 http 请求的 head 中的
请注意是验证信息
head 里加形如 X-Access-Token: xxxxxxxxxxxxxxxxx 的加密信息无误

baiyi

2017-02-03 13:53:23 +08:00

"error": false

这一条不是多余吗

有错误返回错误,没错误不返不就好了

wuzhizhan

2017-02-03 14:34:30 +08:00

"error":false ，换成 retCode 之类的状态码更好些。

ragnaroks

2017-02-03 15:13:24 +08:00

@baiyi #6
可能是客户端有实体

void1900

2017-02-03 15:31:48 +08:00

https

baiyi

2017-02-03 15:52:14 +08:00

@ragnaroks 唔...没接触过客户端开发,刚搜索了下实体对象,应该也可以在判断 HTTP status codes 为失败的时再创建,也就是说,成功是还是可以省略的

erming

2017-02-03 17:26:43 +08:00

@baiyi 有时候并不是要返回错误，如：去获取一个商品时，由于某些原因商品 ID 没获取的，这时间我们返回一个提示性的数据“商品 ID 错误！”
实际项目的根据自己的需求来定格式就行了，这不是一个规范。

recall704

2017-02-03 17:28:29 +08:00 via iPhone

jwt

appstore001

2017-02-03 17:30:07 +08:00

每个开发者都需要这些东西，只是一般人想不了这么多，技术上也实现不了

erming

2017-02-03 17:32:37 +08:00

@CFO
不是说 get 请求要把信息放在 head 中，是说有些信息可以放到 head 里面
如： app 版本是 1.0 的，在请求服务器接口时 head 中加入 App-Version: 1.0
这是我们的做法，对您只是一个建议。

sobigfish

2017-02-03 17:32:37 +08:00

jwt.io

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

erming

2017-02-03 17:35:20 +08:00

@Kilerd 虽然可以暴力破解，但现在应用的依然很广泛。

erming

2017-02-03 17:35:46 +08:00

@airyland 学习了^v^

hcymk2

2017-02-03 17:35:58 +08:00

又来了。 V2EX 能发投票贴么？

Kilerd

2017-02-03 17:44:39 +08:00 via iPhone

@erming 不懂为什么还要用这种能被破解的算法。顺便说下， RC4 已经能被破解了（不是遍历）。
有更好性能，更安全的算法不用，一定要等到被脱裤了才来哭，才来抱怨？

erming

2017-02-04 08:46:14 +08:00

@baiyi 恩都可以，我们想定义统一的格式，这样客服端只解析一种格式然后做业务判断，而不是兼容的去解析很多种格式。
@Kilerd 不是说非要用 md5 或 RC4 ，也不是说不能用，关键看你要怎么用。

annielong

2017-02-04 13:42:39 +08:00

看习惯了，还是喜欢先来一个统一的定义码，后面跟着信息

publicAdmin

2017-02-04 13:56:42 +08:00

@erming 请教下，关于产品迭代过程中后端和移动端的版本兼容你们是如何处理的呢？

erming

2017-02-04 14:06:00 +08:00

@publicAdmin 后端接口以兼容为主，如果业务逻辑变化比较大，会新开接口

publicAdmin

2017-02-04 14:20:43 +08:00

@erming 针对业务逻辑变化较大的新开了接口后，用户 App 没更新至最新版（同时没法做热修复），是强更客户端还是后端部署 2 套代码靠路由来控制请求版本？

erming

2017-02-04 14:37:19 +08:00

@publicAdmin 强制让用户更新体验不太好，我们规定在客户端请求接口时都要在 head 中加入版本号，如果接口有变化，服务端判断版本号后转发到对应接口上处理，客户端不需要做判断，这样做是因为一旦一个版本发布后更新是很困难的。

mingyun

2017-02-04 23:40:19 +08:00

jwt +1

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 足矣。

jcuan

2017-02-06 00:03:50 +08:00 via Smartisan T1

以前我也用 true 和 false ，不过后来发现分辨错误还是不够用， errorMsg 也不是总能提示给用户的，而且总觉得这种提示信息由前端小伙伴控制比较好～～
还是用 errorCode 错误码比较棒。
最近刚用的:
0-没错误
1-9 服务器错误
10-99 前端参数错误
100-用户输入错误～～

erming

2017-02-06 08:54:38 +08:00

@jcuan 恩恩，很好。