I've just read this very interesting article: Principles for Standardized REST Authentication and I'm wondering why one should sign REST queries even when using SSL. In my understanding, signing REST queries lets the server ensure requests come from trusted clients.
Having said that, is signing really necessary considering that SSL also protects against man-in-the-middle attacks?
数字签名具有法律含义，例如不可否认性，这是任何价值交易都应要求的。这不仅仅是身份验证的问题。实际交易中的数字签名在法庭上是比“此对话是通过 SSL 进行的并具有相互身份验证的证据，因此它一定是被告法官阁下”更强有力的证据。
正如HTTPS 的维基百科文章所述：
[...] HTTPS 提供对网站和与之通信的相关 Web 服务器的身份验证，从而防止中间人攻击。此外，它还提供客户端和服务器之间通信的双向加密，从而防止窃听和篡改和/或伪造通信内容。在实践中，这提供了一个合理的保证，即一个人正在与一个想要与之通信的网站进行通信（而不是冒名顶替者），并确保用户和网站之间的通信内容不会被阅读或伪造由任何第三方。[...]
这就是您需要 HTTPS 的原因，以便客户端“确定”它的请求被发送到正确的目的地。您链接的文章也说：
如果您不验证服务器的 SSL 证书，您不知道谁在接收您的 REST 查询。
但是 HTTPS 通常不会对客户端进行身份验证，除非您将服务器配置为从客户端请求证书以执行相互身份验证。如果您阅读您链接的帖子中的评论，您会看到人们提到这一点：
如果您要使用 https，为什么不完全使用它，并要求客户端证书呢？那么你就得到了一个完全 RESTful 的认证方式，因为客户端和服务端都是在连接层进行认证的，不需要把认证带入 URI 层。
但是带有客户端证书的 HTTPS 更加昂贵和复杂，因此大多数 API 提供商保留“正常”的 HTTPS 来识别服务器并使用更轻的机制来识别客户端：API 密钥。API 密钥基本上由一个公开的名称（例如“Johnny”）和一个私有的密钥（例如一长串随机生成的字符）组成。
当您向服务器发出请求时，您在 URL 中包含名称“Johnny”，以便服务器知道是谁发送了请求。但是服务器不只是盲目地相信你是“Johnny”，你必须通过使用密钥签署请求来证明它，因为它是私有的，只有真正的“Johnny”知道。