搞得我每次调试时都很郁闷
HTTPS 不是已经很完善了吗，上面四种哪些是瞎搞呢，应该做设计怎么做既可以简单实现，方便自己和他人调试，又足够安全呢？
加了 token 才能让银行知道你是你，但是银行不知道你带的东西是你自己带的，还是别人塞进你包里的。
加上 nonce 和签名，才能让银行知道这些东西全都是你带的，别人没有夹带，但是银行不知道这个你，是否是用 1 年前的你克隆出来的。
加上时间戳，银行才能确定面前的你确实是当前时间点真实存在你，东西也是你带的东西。
最后，稀奇古怪的加密又是什么呢？
答：你带的东西是一个保险箱~
所以一个都不能少吗？
另外我倒数第二句不是疑问句，是设问句，答案就在最后一行啊。
从实际角度来说，这样做也确实存在一定的意义，因为 https 的流量卸载很有可能在负载均衡那一步就进行了，如果没有这个二次加密，那么数据在负载均衡那一步就是 『裸』的了，而多了这一层加密，可以让数据在到达业务代码部分时才被解谜。
总结一下就是：
API 签名保证的是应用的数据安全和防篡改，并且可以作为业务的参数校验和处理重放攻击。
HTTPS 保证的是运输层的加密传输，但是无法防御重放攻击。
换句话说，HTTPS 保证通过中间人攻击抓到的报文是密文，无法或者说很难破解。但仍然可以将报文重发，形成 DDOS。同时，如果不签名，只用 HTTP 简单认证，通过抓包，直接可以获取到 Authorization，就可以随意发起请求了。因此最安全的方法就是结合 HTTPS 和 API 签名。
要的是 『尽可能安全』
HTTPS 的服务端收到请求，加上这些验证，还有什么遗漏吗？
响应时，有什么措施是必须采纳的呢？
比如说 客户端是否要对 https 证书进行强验证（不止验证证书有效性，还要验证证书是否一致）。
比如说 时间戳+签名 需要有时间差冗余，避免时间不一致导致出错，而冗余就带来了短时间内重放的风险，此时又需要缓存若干个请求信息来防止短时间内的重放。
比如说 你的 token 机制是否足够安全，是否有吊销机制（ JWT 出来挨打）。
每个措施，一般都是对应某个场景给出的，其实还是确认场景的问题。
另外回应你附言中的问题：
content-type 是 json 的话，签名可以放进 header，也可以给 json 再罩一层 “非签名” 区域。
即：参与签名运算的只是某个子字段，而另一个子字段存储签名信息即可。
但是这里需要注意：
JSON 的 k-v 是无序的，且 JSON 序列化的格式是可以自定义的，当你期望对一个 JSON 求签名（ hash ）的时候，请务必协调好两端的 JSON 序列化格式及顺序。
如果觉得麻烦，也可以选择将需要传递的 JSON 对象，先序列化之后，存于某个 JSON String 字段。
> 对于请求，body 一般只能读取一次，读取时要先缓存一份，然后和请求首部比对
这段话我没有理解是什么意思，为什么只能读取一次。
可以考虑设置类似 “API 网关” 的概念，所有请求先经过网关的核验之后再传入业务代码。
防重放准备这样做
1.验证签名防篡改
2.判断服务器时间是否比请求 timestamp
3.判断 nonce 是否 redis set 中
是考虑 json 的字段可以嵌套和 k-v 无序，才将整个 body hash