HTTP GET请求状态204 Vs 404

Nav*_*dav 16 rest httpresponse http-status-code-404

我有2个资源用户和相册.用户有一个专辑列表.要获得专辑,有2个REST API.

  1. user/{userId}/albums/{albumId}如果找不到,则按albumId获取相册返回404
  2. user/{userId}/albums通过userId获取所有相册.在这种情况下,如果用户没有相册,那么状态代码204或404是什么?

JHH*_*JHH 29

没有任何专辑真的被视为错误吗?假设相册作为JSON数组返回,对这种情况的常见响应将是一个HTTP 200,其中一个空数组作为正文.

返回404表示该资源不存在,有人说甚至不可能要求该特定用户的专辑列表.但实际上,可以成功返回专辑列表,只是列表是空的.这对我来说似乎并不特别.这与使用不存在的ID(使用您的其他端点)检索一个特定相册完全相反; 在这种情况下,404是正确的.

虽然204似乎比404更好,因为它至少告诉客户要求成功但没有内容,它的意图并不是真的被用来表示"成功缺席".相反,它表示资源存在,但由于某种原因,服务器选择不在响应主体中包含资源 - 例如,请求的目的可能是简单地将一些标头传回客户端.

204也可以用作对POST请求的响应,其中某些动作由服务器执行而不必创建任何新资源(这意味着暗示201 CREATED),或者由于某些其他原因而无法返回任何新资源资源.

我认为很明显你需要的是一个

GET /user/xxx/albums

HTTP/1.1 200 OK

[]
Run Code Online (Sandbox Code Playgroud)

  • 我不同意.有数据,一个空数组.恕我直言,强迫客户端对列表进行完全有效的查询 - 暂时恰好是空的 - 作为*错误*会很奇怪,所以我们同意排除404.但是,204对我来说特别适用于客户实际上不想要或不能给予任何资源的地方.我见过的大多数api会使用一个空阵列,我不明白为什么它会以任何方式引起争议.在普通客户端编程中,您是否更喜欢null而不是空列表? (7认同)
  • 200表示请求成功,并且响应中有数据。在这种情况下,响应中没有数据,因此204实际上是要返回的正确状态代码。现在,如果您调用GET / user / xxx / albums,其中xxx是不存在的用户,那么我将返回404并显示一条消息,指出未找到什么资源。由于这是GET,因此与您收到204的POST的典型情况没有任何混淆。在一天结束时,您的API应该有文档告诉开发人员哪些状态代码表示特定请求的含义。 (2认同)

Sap*_*rel 10

错误代码404

当用户尝试跟踪损坏或死链接时,网站托管服务器通常会生成"404 Not Found"网页.

返回代码204

服务器已完成请求但不需要返回实体主体.

结论

你显然需要提出204错误.如果您使用404,用户可能会受到干扰.此外,当目标相册不存在时,您使用404.对于1和2使用404是缺乏逻辑的.

  • 只是指出204不是错误代码. (21认同)

Jef*_*ima 9

以下是定义HTTP协议的RFC2616所说的状态代码:

Status-Code的第一个数字定义了响应类.最后两位数字没有任何分类角色.第一个数字有5个值:

  - 1xx: Informational - Request received, continuing process

  - 2xx: Success - The action was successfully received,
    understood, and accepted

  - 3xx: Redirection - Further action must be taken in order to
    complete the request

  - 4xx: Client Error - The request contains bad syntax or cannot
    be fulfilled

  - 5xx: Server Error - The server failed to fulfill an apparently
    valid request
Run Code Online (Sandbox Code Playgroud)

在您的情况下,请求成功,但没有要显示的相册,因此您肯定应该使用2xx类别中的状态.

以下是RFC关于204状态的说明:

10.2.5 204没有内容

服务器已完成请求但不需要返回实体主体,并且可能希望返回更新的元信息.响应可以包括实体标题形式的新的或更新的元信息,如果存在,应该与所请求的变体相关联.

如果客户端是用户代理,它不应该从导致请求发送的文档视图中更改它的文档视图.此响应主要用于允许在不导致更改用户代理的活动文档视图的情况下进行操作的输入,尽管任何新的或更新的元信息应该应用于当前在用户代理的活动视图中的文档.

204响应绝不能包含消息体,因此总是在头字段之后的第一个空行终止.

RFC声明204主要用于允许输入,因此您不应使用此输入.在这种情况下我会使用200.


小智 6

当你请求一个特定的资源,比如一个用户,而该用户不存在,那么你应该返回 404。例如,你有一个 API 来使用以下 URL 检索用户:

https://yourdomain.com/api/users/:userid
Run Code Online (Sandbox Code Playgroud)

并且请求检索不存在的用户 1234,那么您应该返回 404。在这种情况下,客户端请求了一个不存在的资源。

https://yourdomain.com/api/users/1234 
404
Run Code Online (Sandbox Code Playgroud)

现在假设您有一个 api,它使用以下 url 返回系统中的所有用户:

https://yourdomain.com/api/users
Run Code Online (Sandbox Code Playgroud)

如果系统中没有用户,那么在这种情况下,您应该返回 204。

  • 错误的是,服务器可以理解您尝试访问的资源,它可以根据 URI 理解哪个进程,因此不应使用 404。 (2认同)

Raf*_*med 6

让我为此付出 2 美分。我希望您已经知道 404 与 204 之间的区别。我更喜欢使用每个状态代码的场景是:

404 状态代码

404 表示资源未找到或不存在或 URL 无效

例如

GET : https://api.myapp.io/product/product_id_123
GET : https://api.myapp.io/image/nokia.jpg
Run Code Online (Sandbox Code Playgroud)

如果数据库或资源文件夹中不存在单个产品/资源项,则意味着该 URL 的资源无效,因此我们必须抛出 404,并且像 Google 和 bing 这样的搜索引擎将不会缓存结果,也不会第二天重试以获得新内容。

204 状态代码

204 表示 URL 有效,服务器已成功执行,但没有数据可返回。

例如

GET : https://api.myapp.io/product/search?keyword=nokia
Run Code Online (Sandbox Code Playgroud)

如果数据库中没有与该关键字匹配的数据(单个或多个)返回结果,则抛出 204,因为没有数据可返回,但 URL 仍然有效,Google 和 bing 等搜索引擎将在下一次重试新鲜内容的一天,因为对他们来说,这不是无效的网址,当您第二天重试时,可能会有一些与查询匹配的数据。