讨论关于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

TeemoWang
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 22
╰ゝSakura

能不能给个具体的示例

1年前 评论
TeemoWang (楼主) 1年前
Mutoulee

强迫症犯了? :smile:

1年前 评论
TeemoWang (楼主) 1年前

选1

1年前 评论
TeemoWang (楼主) 1年前
TeemoWang (楼主) 1年前

选 1

1年前 评论
TeemoWang (楼主) 1年前
nfangxu

根据具体业务来区分就好了, 比如说, 你有一个全局的 appkey 需要统一处理, 推荐放在 URL 或者 header 中, 在这里可以不解析body即可取得, 可以交给全局服务来处理, sign 如果需要根据body(如key排序等)来生成的话, 就放到body中, 如果只需要用到body, 并不需要解析的话, 就放到 URL或者header中, 统一处理, 这样只需要读取body中的字符串就可以校验

1年前 评论
TeemoWang (楼主) 1年前
  1. boder 和 header分开传输,当body非常大时,后端可以先解析head中的身份认证参数,当认证失败时,可以不再传输body,达到快速响应以及节省流量。

  2. 前端也好封装,统一管理简单啊

所以放header里吧

1年前 评论
Bear_zheng 1年前
Bear_zheng

1好些,安全校验和业务处理隔离,各司其职。header中的业务逻辑是固定的,单独出个中间件处理就不用管了

1年前 评论

我一直用的2,laravel框架也不存在传输位置的问题,只要传参,它都能接收到

1年前 评论

微信,抖音和快手对外开发接口也是使用的3,系统参数url,业务body

1年前 评论

说一下我们目前的接口

  1. 系统参数,比如,app-key | signature 等参数,放在header里面
  2. 业务数据,放在body中
  3. 全post方式,没有gei方式
  4. 业务数据,全部都是json格式
1年前 评论

肯定选1 你说这几个参数可以这样细分

appkey 参数 请求app的标识

app通过appkey和appsecret获取有效期token, 后端通过token可以确定appkey

sign 签名

应该是为了接口安全, 把token做好, 这个可有可无

timestamp 时间戳

感觉不用传递, 后端接口记录请求时间, 写到监控日记中即可

nonce 不知道做啥用的

version 版本

接口url中 应该有接口的版本 如 /v1/user/get 以后新接口升级好做些, 直接升级 /v2/user/get

1年前 评论
cevin 1年前
aab

前一段我也在整理这个东西,你可以参考一下这几个方案
help.aliyun.com/document_detail/31...

cloud.tencent.com/document/product...

developer.qiniu.com/insight/4814/t...

1年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!