讨论关于api接口设计，公共参数传递问题
讨论api接口的公共参数(appkey,sign,timestamp,nonce,version)到底如何传值更好,更优雅?
目前公司业务升级,在用laravel重新设计开放接口,以前用的是下面第二种方式全放body-json,但是觉得系统参数和业务参数混合,是不是不太优雅?看的越多越纠结,纠结ing~ ,翻看咱们论坛好像没有找到类似问题,各位大佬请指点一下。
因为平时工作中也对接了很多平台接口,做了几个总结,目前大致归为三大类(好像也只能通过这三大类传递)
1.通过headers和body传递
将系统参数(headers)和业务参数(body)完全隔离开,分别处理;
2.通过body
将系统参数和业务参数放在一起一个json传递;(pdd的sdk用的这个方法)
3.通过URL
将系统参数放入Url请求串,业务参数放入body-json中;(tb用的这个方法,jd也是,ps,jd好像抄袭了tb的sdk架构?)
开发语言是php
关于 LearnKu
粤公网安备 44030502004330号
能不能给个具体的示例
强迫症犯了？ :smile:
选1
选 1
根据具体业务来区分就好了, 比如说, 你有一个全局的 appkey 需要统一处理, 推荐放在 URL 或者 header 中, 在这里可以不解析body即可取得, 可以交给全局服务来处理, sign 如果需要根据body(如key排序等)来生成的话, 就放到body中, 如果只需要用到body, 并不需要解析的话, 就放到 URL或者header中, 统一处理, 这样只需要读取body中的字符串就可以校验
boder 和 header分开传输，当body非常大时，后端可以先解析head中的身份认证参数，当认证失败时，可以不再传输body，达到快速响应以及节省流量。
前端也好封装，统一管理简单啊
所以放header里吧
1好些，安全校验和业务处理隔离，各司其职。header中的业务逻辑是固定的，单独出个中间件处理就不用管了
我一直用的2,laravel框架也不存在传输位置的问题,只要传参,它都能接收到
微信,抖音和快手对外开发接口也是使用的3,系统参数url,业务body
说一下我们目前的接口
肯定选1 你说这几个参数可以这样细分
appkey 参数 请求app的标识
app通过appkey和appsecret获取有效期token, 后端通过token可以确定appkey
sign 签名
应该是为了接口安全, 把token做好, 这个可有可无
timestamp 时间戳
感觉不用传递, 后端接口记录请求时间, 写到监控日记中即可
nonce 不知道做啥用的
version 版本
接口url中 应该有接口的版本 如 /v1/user/get 以后新接口升级好做些, 直接升级 /v2/user/get
前一段我也在整理这个东西，你可以参考一下这几个方案
help.aliyun.com/document_detail/31...
cloud.tencent.com/document/product...
developer.qiniu.com/insight/4814/t...