Question

我正在实现一个API，并且我想返回一个指示符，表明一个实体存在，例如，它要检查后端是否存在订单。...

GET    /order/:order-ref

我可以这样返回JSON负载：

{
  true
}

但是看起来很重。我当时只是想返回一个HTTP状态来表示相同的意思。在这种情况下，什么HTTP状态正确？

Answer 1

似乎很重。

作为CodeCaster pointed out，这不是有效的JSON，我不明白如何将其视为沉重。

我当时只是想返回一个HTTP状态来表示相同的内容。

根据您的需要，可以使用HEAD方法。它与GET请求相同，除了响应将仅包含状态行和标头，而没有任何有效载荷。

HEAD /orders/1 HTTP/1.1
Host: example.org

引用RFC 7231，该文档定义了HTTP / 1.1协议的语义和内容：

4.3.2. HEAD

HEAD方法与GET相同，不同之处在于服务器在响应中不得发送消息正文（即，响应在标头部分的结尾处终止）。 [...]

在这种情况下哪种HTTP状态正确？

如果资源存在，则返回200。否则返回404。

HTTP/1.1 200 OK
Date: Tue, 8 Oct 2019 13:39:14 GMT

HTTP/1.1 404 Not Found
Date: Tue, 8 Oct 2019 13:39:14 GMT

Answer 2

但是看起来很重

除了它是无效的JSON之外，真的是4个字节（如果返回true或18个字节（{ "exists": true }）那么“重”吗？

如果客户想查看实际的订单数据，又需要另一个电话怎么办？

究竟哪一部分是“繁重的”，通过已经打开的连接返回几个字节，或者连接并搜索数据库以确定实际顺序是否存在？

但是，如果您确实想节省一些字节，则可以返回空的200 OK或204 No Content。但是我建议不要这样做，

Answer 3

似乎很重

它很重-您试图表示一点（打开/关闭），并且这样做是在拖动整个HTTP标头。根据您使用的工具，您也许可以减少标题集合，但是您会感到很沉重。

在这种情况下哪种HTTP状态正确？

确实没有一个很好的答案。在某些情况下，您将看到用204表示某物存在，用404表示不存在。那不是正确的事情；通用组件不会以这种方式解释状态行。但是，如果您控制客户端，或者能够带外传达语义，那么可能不会太痛苦。

Github Starring API以这种方式工作。

GET /user/starred/:owner/:repo

这是仅在有星星时才存在的资源-它的表示长度为零字节。如果要求提供不存在的恒星的表示形式，则会得到一个explanation of the error situation，它也是个零字节长。

另一方面，HEAD“用于在不传输表示数据的情况下获取有关所选表示的元数据”。这可能更接近您的情况-订单的表示可能是一个很大的文档，但是对于客户的特定用例，仅需要元数据。