erming
V2EX  ›  PHP

关于 app 接口开发

  •  
  •   erming · Feb 3, 2017 · 5810 views
    This topic created in 3564 days ago, the information mentioned may be changed or developed.

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

    Supplement 1  ·  Feb 3, 2017
    其实 app 接口开发涉及很多细节问题。
    微信 /支付宝 /支付 友盟统计 消息推送(单人推送,群发,按标签推送,按版本推送等,有时候运营要知道到达率等等)
    渠道统计,广告统计,针对单用户的各种统计。
    包括客户端服务端异常监控等。
    大家互相学习,不喜勿喷,谢谢!
    30 replies  •  2017-02-06 08:54:38 +08:00
    airyland
    airyland
    Feb 3, 2017 via iPhone❤️2
    1
    md5 不是加密算法
    Kilerd
    Kilerd
    Feb 3, 2017 via iPhone
    2
    MD5 , RC4 已经不安全
    Sentur
    Sentur
    Feb 3, 2017
    3
    我选择倒叙加密 #滑稽
    CFO
    CFO
    Feb 3, 2017 via Android
    4
    get 请求是把信息放在 head 中的?谁告诉你的?
    weiceshi
    weiceshi
    Feb 3, 2017
    5
    @CFO
    楼主是说:把一些验证信息放到 http 请求的 head 中的
    请注意是验证信息
    head 里加形如 X-Access-Token: xxxxxxxxxxxxxxxxx 的加密信息无误
    FinnBai
    FinnBai
    Feb 3, 2017
    6
    "error": false

    这一条不是多余吗

    有错误返回错误,没错误不返不就好了
    wuzhizhan
    wuzhizhan
    Feb 3, 2017
    7
    "error":false ,换成 retCode 之类的状态码更好些。
    ragnaroks
    ragnaroks
    Feb 3, 2017
    8
    @baiyi #6
    可能是客户端有实体
    void1900
    void1900
    Feb 3, 2017
    9
    https
    FinnBai
    FinnBai
    Feb 3, 2017
    10
    @ragnaroks 唔...没接触过客户端开发,刚搜索了下实体对象,应该也可以在判断 HTTP status codes 为失败的时再创建,也就是说,成功是还是可以省略的
    erming
    erming
    OP
    Feb 3, 2017
    11
    @baiyi 有时候并不是要返回错误,如:去获取一个商品时,由于某些原因商品 ID 没获取的,这时间我们返回一个提示性的数据“商品 ID 错误!”
    实际项目的根据自己的需求来定格式就行了,这不是一个规范。
    recall704
    recall704
    Feb 3, 2017 via iPhone
    12
    jwt
    appstore001
    appstore001
    Feb 3, 2017
    13
    每个开发者都需要这些东西,只是一般人想不了这么多,技术上也实现不了
    erming
    erming
    OP
    Feb 3, 2017
    14
    @CFO
    不是说 get 请求要把信息放在 head 中,是说有些信息可以放到 head 里面
    如: app 版本是 1.0 的,在请求服务器接口时 head 中加入 App-Version: 1.0
    这是我们的做法,对您只是一个建议。
    run2
    run2
    Feb 3, 2017
    15
    FinnBai
    FinnBai
    Feb 3, 2017
    16
    @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
    erming
    OP
    Feb 3, 2017
    17
    @Kilerd 虽然可以暴力破解,但现在应用的依然很广泛。
    erming
    erming
    OP
    Feb 3, 2017
    18
    @airyland 学习了^v^
    hcymk2
    hcymk2
    Feb 3, 2017
    19
    又来了。 V2EX 能发投票贴么?
    Kilerd
    Kilerd
    Feb 3, 2017 via iPhone
    20
    @erming 不懂为什么还要用这种能被破解的算法。顺便说下, RC4 已经能被破解了(不是遍历)。
    有更好性能,更安全的算法不用,一定要等到被脱裤了才来哭,才来抱怨?
    erming
    erming
    OP
    Feb 4, 2017
    21
    @baiyi 恩都可以,我们想定义统一的格式,这样客服端只解析一种格式然后做业务判断,而不是兼容的去解析很多种格式。
    @Kilerd 不是说非要用 md5 或 RC4 ,也不是说不能用,关键看你要怎么用。
    annielong
    annielong
    Feb 4, 2017
    22
    看习惯了,还是喜欢先来一个统一的定义码,后面跟着信息
    publicAdmin
    publicAdmin
    Feb 4, 2017
    23
    @erming 请教下,关于产品迭代过程中后端和移动端的版本兼容你们是如何处理的呢?
    erming
    erming
    OP
    Feb 4, 2017
    24
    @publicAdmin 后端接口以兼容为主,如果业务逻辑变化比较大,会新开接口
    publicAdmin
    publicAdmin
    Feb 4, 2017
    25
    @erming 针对业务逻辑变化较大的新开了接口后,用户 App 没更新至最新版(同时没法做热修复),是强更客户端还是后端部署 2 套代码靠路由来控制请求版本?
    erming
    erming
    OP
    Feb 4, 2017❤️1
    26
    @publicAdmin 强制让用户更新体验不太好,我们规定在客户端请求接口时都要在 head 中加入版本号,如果接口有变化,服务端判断版本号后转发到对应接口上处理,客户端不需要做判断,这样做是因为一旦一个版本发布后更新是很困难的。
    mingyun
    mingyun
    Feb 4, 2017
    27
    jwt +1
    chinvo
    chinvo
    Feb 5, 2017
    28
    状态码我一般这样设计

    Success:

    {"status": 0}

    Success with result:

    {"status": 1, "result":<object>}

    Faild:

    {"status": -n, message: "xxx"}

    至于消息加密,个人认为 HTTPS 足矣。
    jcuan
    jcuan
    Feb 6, 2017 via Smartisan T1
    29
    以前我也用 true 和 false ,不过后来发现分辨错误还是不够用, errorMsg 也不是总能提示给用户的,而且总觉得这种提示信息由前端小伙伴控制比较好~~
    还是用 errorCode 错误码比较棒。
    最近刚用的:
    0-没错误
    1-9 服务器错误
    10-99 前端参数错误
    100-用户输入错误~~
    erming
    erming
    OP
    Feb 6, 2017
    30
    @jcuan 恩恩,很好。
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   1542 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 65ms · UTC 04:14 · PVG 12:14 · LAX 20:14 · JFK 23:14
    ♥ Do have faith in what you're doing.