java - 为什么在 JSON 负载请求正文中发送 http 请求元数据被认为是不好的做法，而最好使用请求 header ？

Question

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

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服务应用层来说，需要“只看一处”才能完成业务逻辑。
业务逻辑验证 token 是否有效，如果是，则解析 action , product , 和 price字段并执行业务逻辑。如果 token 无效，它会响应错误。这可以通过仅解析一个地方来完成，即 JSON 有效负载。
为什么这被认为是一个糟糕的设计？
查看在线示例，许多使用 token 位于标题中的设计。 (但两者都可以看到!)更像是:

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

为什么把所有东西都放在一个地方的设计不是更好？而是将 header 中的 token 分开。
这不是意见问题。我确信将 token 放在标题中而不是正文中是有原因的。

Answer 1

资源“操作”由 Action 、产品和价格组成。创建新操作时，您需要传递操作、产品和价格。
不过， token 不是操作的一部分:它是一种元数据，出于安全目的需要与请求一起发送。从技术上讲，您不需要 token 来创建操作。
使 HTTP 请求和响应的主体包含正在处理的资源的表示，可以产生一个可以说更优雅的 API，更接近 REST 的全部内容:资源。
即使是后端，它也应该允许您在请求处理程序之间共享 DTO。大多数框架通过某些类型的 HTTP 过滤器来处理安全问题，让您的请求处理程序非常专注于业务(应该如此)。