我有以下端点,它的快乐路径是:
GET /messages/next
Response:
{
"date_published": "...",
"message": "..."
}
通常,响应如上所述,但有时候根本没有“下一步”消息。我的问题是,在没有“下一条”消息的情况下,我是否回复了HTTP 204(无响应),还是应该只返回{}
?
在这种情况下,最佳做法是什么?
答案 0 :(得分:3)
根据W3: 10.2.5 204无内容
服务器已完成请求但不需要返回 entity-body,可能想要返回更新的元信息。
我认为在你的情况下,返回一个204 Http响应是合适的,除非由于某种原因,JSON有效负载会为你的程序做出更好的设计决策(即你想要返回的东西不仅仅是元信息因为204不允许返回消息体。
另外,请看一下这篇文章:REST API error return good practices
答案 1 :(得分:2)
204非常棘手。 RFC说
服务器已履行请求,但无需返回实体 - "
因此必须有一个要求,不需要才能返回任何内容。这不是这种情况。对于GET
请求,服务器需要返回资源的表示(如果存在)。所以要么资源不存在,要么返回资源。它不能说"资源很无聊。我不肯归还它。猜猜看起来如何"。
让我们看一下考虑的响应代码:
这些都很相似,但存在细微差别,因为有不同种类的"没有"回来。
也许您有/messages
这样的资源,而GET
显然会返回消息列表。此列表可以为空:[]
(或security reasons而非{"messages": []}
)。返回一个空列表很好,结果是200.与空结果(对应于null)相比,空列表的一个巨大好处是客户端通常可以使用相同的代码处理空列表,因为它处理非空名单。不需要额外的逻辑,这降低了复杂性和错误的可能性。
也许逻辑上没什么可回报的。这通常在您执行PUT
,POST
,DELETE
或PATCH
操作时发生。在这些情况下,您可以返回一个正文(旧/新实体),但您不需要。如果不这样做,请返回204。
可能资源不是空的但不存在。在这种情况下,您应该返回404。
作为类比,将资源视为文件(资源不需要是文件,但它们可以而且对于静态HTML来说很常见,这恰好是HTTP的起源):200表示资源/ file有,但可能是空的。 204表示服务没有义务返回文件。 404表示请求服务器返回文件,但没有要返回的文件。
因此,在您的示例中,GET /messages/next
应在没有下一条消息时返回404,如果有下一条消息则返回200,但此消息为空。它永远不应该返回204。
使用HATEOAS时,如果有下一条消息,则只应链接资源/messages/next
。
或者,您可以拥有资源/messages/newest
并使用条件GET
请求(例如,使用If-Modified-Since
标头)请求资源。
另请查看this nice overview。