【问题标题】:JSON REST Api Pagination page out of bounds or empty collection response codeJSON REST Api 分页页面越界或空集合响应代码
【发布时间】:2015-08-11 09:55:27
【问题描述】:

请寻找一些最佳实践...

场景 1:GET: /api/v1/widgets/?page=10&per_page=5 小部件集合仅包含 10 条记录。所以页面越界了。

场景 2:GET: /api/v1/widgets/ 小部件集合当前为空。

因此,在这两种情况下,我都在寻找合适的状态代码和响应。

我的想法:

  • 422 unprocessable entity 通常用于验证,但是在这种情况下,我认为它是合适的,因为请求的 page 超出范围。特别适用于场景 1
  • 400 bad request因为页面越界:场景1
  • 404 Not found因为资源是空的:场景1&2
  • 204 No Content因为两个集合都返回空数据:场景1和2
  • 200 - with data as empty array 因为 url 有效,但内容不存在。场景 1 和 2

目前是否有这种结构的最佳实践?

【问题讨论】:

    标签: json api rest


    【解决方案1】:

    我建议返回一个空集合和状态码 200。此外,您应该在响应标头中提供超链接以将客户端指向“正确”页面,例如第一页或最后一个“有效”页面。对于集合资源的分页,服务器应始终以指向上一页和下一页的超链接进行响应。

    【讨论】:

    • 非常感谢。意识到设置标题以显示总资源、页面、当前页面等...我只是在寻找最佳实践 http 响应代码。您建议在两种情况下都使用 200 个空数组?
    • 是的。在第二种情况下,它是 200,因为请求是正确的,而只是集合为空。第一种场景,一定不能是404,因为集合资源确实存在(只有请求的页面不存在),也不能是400,因为客户端没有语法错误(发送错误更多是语义错误页码)。不能是422,因为你不发送请求体,比较this。如果服务器“不需要返回实体主体”但可以发送更新的元信息,则应发送状态 204。
    猜你喜欢
    • 1970-01-01
    • 2019-11-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-01-04
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多