Java 为什么在JSON有效负载请求体中发送http请求元数据被认为是不好的做法，而使用请求头则更可取？

我有一个非常简单的应用程序，需要解析这种负载：

curl --location 
--request POST 'https://host.com/operation' \
--header 'Content-Type: application/json' \
--data-raw '{
    "authenticationToken": "xxxxx48cd07046d4886649d7c39171b071ca2af7e0b11a2ba2cfc5080cc01ac",
    "action": "buy",
    "product": "toy",
    "price": "12"
}'

在此服务中，规范请求authenticationToken成为请求主体JSON负载的一部分。原因是，对于web服务应用层，为了完成业务逻辑，需要“只看一个地方”

业务逻辑验证令牌是否有效，如果有效，则解析

操作

、

产品

、和

价格

字段并执行业务逻辑。如果令牌无效，它将响应一个错误。这可以通过只解析一个地方（JSON负载）来完成

为什么这被认为是一个糟糕的设计？

通过查看在线示例，许多人使用了标记位于标题中的设计。（但两者都可以看到！）更像是：

curl --location --request POST 'https://host.com/operation' \
--header 'authenticationToken: xxxxx48cd07046d4886649d7c39171b071ca2af7e0b11a2ba2cfc5080cc01ac' \
--header 'Content-Type: application/json' \
--data-raw '{
    "action": "buy",
    "product": "toy",
    "price": "12"
}'

为什么这不是更好的设计，所有的东西都可以放在一个地方？而是在标头中分隔标记

这不是一个意见问题。我确信令牌放在标题中而不是正文中是有原因的。

资源“操作”由动作、产品和价格组成。创建新操作时，需要传递操作、产品和价格

不过，令牌不是操作的一部分：出于安全目的，它是需要与请求一起发送的元数据。从技术上讲，创建操作不需要令牌

使HTTP请求和响应的主体包含所处理的资源的表示，可以说产生了一个更优雅的API，更接近REST的全部内容：资源

---

即使在后端，它也应该允许您跨请求处理程序共享DTO。大多数框架通过某种HTTP过滤器处理安全性，使您的请求处理程序非常关注业务（这是应该的）。

再加上一点：如果令牌是请求主体的一部分，那么表示请求主体的每个DTO也需要有一个

authenticationToken

字段，如果它希望干净地利用它。