我们可以使用 http 代码 422(Unprocessable Entity) 进行 Get 操作吗？

Question

团队 - 我们在代码中使用 422 HTTP Status Code for validations 进行 HTTP GET 操作。但不确定，我们是否可以使用 get 操作。 422 unprocessable 实体听起来更像是请求正文验证 - 请帮助

谢谢

Answer 1

通常 GET 请求没有 Payload。我们使用 GET 从服务器/数据库中检索数据，这些数据在创建或插入时已经过验证。这意味着我们在检索时不需要验证数据。

如果我们有 Payload，我们应该使用 POST。我们可以根据需要使用 422 或 400 和 POST。

获取

GET 方法意味着检索任何信息（以 entity) 由 Request-URI 标识。如果 Request-URI 指的是 一个数据产生过程，它是产生的数据，应该是 作为响应中的实体而不是源文本返回 进程，除非该文本恰好是进程的输出。

发布

POST 方法用于请求源服务器接受 包含在请求中的实体作为资源的新下属 由 Request-Line 中的 Request-URI 标识。 POST 旨在 允许一个统一的方法覆盖以下功能：

  - Annotation of existing resources;
  - Posting a message to a bulletin board, newsgroup, mailing list,
    or similar group of articles;
  - Providing a block of data, such as the result of submitting a
    form, to a data-handling process;
  - Extending a database through an append operation.

400

400（Bad Request）状态码表示服务器不能或 由于某些被认为是
而不会处理请求 是客户端错误（例如，格式错误的请求语法、无效请求
消息框架或欺骗性请求路由）。

422

422（不可处理实体）状态码表示服务器
了解请求实体的内容类型（因此 a
415（不支持的媒体类型）状态码不合适），
请求实体的语法正确（因此为 400（错误请求）
状态码不合适）但无法处理包含的 指示。例如，如果 XML
请求正文包含格式正确（即语法正确），但
语义错误的 XML 指令。在 RFC 723x 中找不到 422

Source RFC 2616Source RFC 723x

Answer 2

422的描述说，

422（Unprocessable Entity）状态码表示服务器理解请求实体的内容类型（因此 415（Unsupported Media Type）状态码是不合适的），并且请求实体的语法是正确的（因此 400 (Bad Request) 状态码不合适）但无法处理包含的指令。

相反，我认为 400 代码更适合这里。

因此可能有人认为它不适合语义错误。但不再是了；自 2014 年 6 月起，取代之前的 RFC2616 的相关标准 RFC 7231 更广泛地使用了 400（错误请求）作为 由于某些被认为是客户端错误，服务器无法或不会处理请求

Answer 3

422 不可处理的实体可用于任何类型的请求。它不是特定于 GET 或 POST 或 DDELETE。如果您必须验证任何可以作为请求接受的数据并且必须验证任何前置条件，则可以抛出 HTTP 422。

例如。 GET 中有路径参数调用你正在传递的年龄，这在语法上是正确的，比如 16，但你的年龄超过 18 岁的业务逻辑。因此在这里抛出 400 是不正确的。

参考：https://www.restapitutorial.com/httpstatuscodes.html

Answer 4

422 "Unprocessable Entity" 更多是关于语义错误，URI 是 不是请求实体的一部分，因此 422 不适用。