接口签名中，关于空字符不签名和参数排序的原理是什么

  • Z时代
  • 2024-03-04
  • 分类：IT

在很多三方接口中，进行签名时，都要求参数值为空不参与签名，以及参数名需要按ASCII码从小到大排序，这是约定俗成，还是说有技术上的原因的呢？

回答：

既是约定俗成，也是有客观原因的。

首先空参数如果参与签名，当接口字段比较多、且存在大量空字段时，会有很多资源浪费在字符串拼接、和计算字符串签名上面，也就是说原始数据越长、开销越大。所以丢弃空参数有利于提升性能。也许单个请求的开销微乎其微，但当你面对数百万、千万、甚至亿级的流量时，这一点点开销累积起来就很可观了。

其次如果不忽略空参数的话，处理上容易产生歧义。比如很多接口接收的参数其实是实体类型，某个字段究竟是因为压根就没传值而空、还是就是确实传了空值？也就是说：

{ "key": "" }   // 有 Key、值为空字符串
{ "key": null } // 有 Key、值为 null
{ }             // 无 Key

其中后两者语义上其实是没有区别的，但程序处理上其实二者很可能是有区别的，甚至于前俩都可能混淆，这种就很容易造成误解 —— 你说这个 "key" 要不要参与签名？

而字段要按字典排序，这个就很好理解了，因为 Object/Map 这种结构本身无序，那么对于异构系统中，对接双方很可能使用的是不同语言、不同标准库或第三方库、不同序列化方式，造成序列化后的字符串并非顺序一致，所以需要通过某种规定来让双方都能使用一致的方式进行签名。对字段排序就是最简单的手段。

至于最早这种签名方式是谁提出的，我没有找到相关出处。

不过 IETF 是有相关的草案的，即 “HTTP Signatures” （文件链接见下方）。IETF 就是制定 RFC 标准的那个组织，比如 HTTP 协议的规范就是由若干个 RFC 标准组成。目前草案进行到第八版，第一版是 2014 年提出的，但有这种签名方式肯定要比 2014 更早。

https://tools.ietf.org/html/d...

目前我能找到的最早的类似的实现方案，是 2007 年 OAuth 标准在制订时提出的一个叫做 “OAuth Request Body Hash” （文件链接见下方）的草案，虽然最后因为种种原因它最后没有被纳入到 OAuth 标准中去，但确实是较早提出的了。

https://tools.ietf.org/id/dra...

回答：

约定俗成
空参数有的地方可能会拼出 a=null ，有些地方可能拼出 a= ，干脆省略
参数按字母排序，不用给每个接口都定义字段顺序

以上是 接口签名中，关于空字符不签名和参数排序的原理是什么 的全部内容， 来源链接： utcz.com/p/944183.html

回到顶部