小编典典

带有 URL 查询参数的 HTTP POST——好主意还是不好?

all

我正在设计一个通过 HTTP 的 API,我想知道是否使用 HTTP POST 命令,但只有 URL 查询参数,没有请求正文,是一个好方法。

注意事项:

  • “良好的 Web 设计”需要通过 POST 发送非幂等操作。这是一个非幂等的动作。
  • 当请求参数存在于 URL 中时,更容易开发和调试此应用程序。
  • API 不适合广泛使用。
  • 似乎发出没有正文的 POST 请求需要更多的工作,例如Content-Length: 0必须显式添加标头。
  • 在我看来,没有正文的 POST 也有点违背大多数开发人员和 HTTP 框架的期望。

通过 URL 查询而不是请求正文在 POST 请求上发送参数是否有更多的陷阱或优势?

编辑:正在考虑的原因是这些操作不是幂等的,并且除了检索之外还有副作用。请参阅HTTP
规范

特别是,已经建立了约定,即 GET 和 HEAD
方法不应该具有采取除检索之外的操作的意义。这些方法应该被认为是“安全的”。这允许用户代理以特殊的方式表示其他方法,例如 POST、PUT 和
DELETE,以便用户意识到正在请求可能不安全的操作。

方法还可以具有“幂等性”的属性,因为(除了错误或过期问题)N > 0 个相同请求的副作用与单个请求相同。GET、HEAD、PUT 和 DELETE
方法共享此属性。此外,方法 OPTIONS 和 TRACE 不应该有副作用,因此本质上是幂等的。


阅读 116

收藏
2022-03-09

共1个答案

小编典典

如果您的操作不是幂等的,那么您 必须 使用POST. 如果你不这样做,你只是在自找麻烦。 GETPUT并且DELETE方法 必须
是幂等的。想象一下,如果客户端为您的服务预取所有可能的GET请求,您的应用程序会发生什么——如果这会导致客户端可见的副作用,那么就出了问题。

我同意发送POST带有查询字符串但没有正文的 a 似乎很奇怪,但我认为在某些情况下它可能是合适的。

将 URL 的查询部分视为对资源的命令,以限制当前请求的范围。通常,查询字符串用于对GET请求进行排序或过滤(如),但我认为在
a上限制范围也是?page=1&sort=title有意义的(也许如)。POST``?action=delete&id=5

2022-03-09