【问题标题】:Rest Api Return休息 API 返回
【发布时间】:2019-07-18 07:57:37
【问题描述】:

我正在构建一个 rest api 并且想知道返回错误。目前,我的计划是使用 http 状态码,但也总是返回结果。如果发生错误,结果将如下所示。

{
"Data":[the data],"
Errors":[the errors]
}

基本上,如果发生错误,将返回 4xx 或 5xx 的 Http 状态代码,并且返回的 JSON 中的 Errors 集合将包含有关错误的更多详细信息,其中 Data 部分为空。如果调用成功,将返回 200 的 Http 状态代码以及包含请求数据的数据元素,并且错误元素将为空。

这是返回带有错误信息的数据的好方法吗?

【问题讨论】:

    标签: rest


    【解决方案1】:

    在我的设计中,我没有在响应 JSON 对象中同时包含“数据”和“错误”属性。

    如果 API 成功,我将只返回“数据”。而且http状态码是2XXX。

    如果 API 失败,我将返回一个“错误”对象。 http 状态遵循 RFC 2616 第 10 节中定义的规范。

    我的错误对象的示例如下。

    HTTP/1.1 404 Not Found
    X-Powered-By: Express
    Content-Type: application/json; charset=utf-8
    Content-Length: 100
    Date: Thu, 08 Nov 2012 07:07:05 GMT
    Connection: keep-alive
    
    {
      "type": "error",
      "status": 404,
      "message": "Not Found",
      "help_url": "/api/help.html"
    }
    

    【讨论】:

    • 您应该更新您对 RFC 2616 的引用,以指向 RFC 7231(或其配套的 RFC 7230-7235 之一),因为 HTTP 背后的工程师之一 Mark Nottingham 表示 RFC 2616 is dead跨度>
    【解决方案2】:

    我也在使用这种方法。我知道这不符合标准约定。但是无所谓。我认为无论哪种方式都可以争论。就我个人而言,我的 API 不是公开可用的(它们都在我的应用程序内部使用)。所以我认为这是一种“视情况而定”的情况。

    我所有的 API 都返回带有 T 模板有效负载的相同数据结构。数据结构本身很好,因为消费者拥有他们需要的一切(成功状态、错误代码、错误详细信息,当然还有数据负载本身)。

    这样我的表示层可以以友好的方式统一处理所有 http 响应。

    【讨论】:

    • 这里的问题是,您将元数据与实际内容混合在一起,这可能会分散客户对实际任务的注意力。对于内部的东西,不需要 REST(真正意义上的),因为通常可以同时控制客户端和服务器。对于拥有大量客户端的 API,尤其是那些不受您控制的 API,情况看起来有所不同。 RFC 7807application/problem+json(或 xml)的名义指定自己的错误消息格式,如果 HTTP 状态代码不够,则标准化错误详细信息可能返回给客户端的方式
    • @RomanVottner - 谢谢。现在我真的在考虑取消我认为的好主意。现在我应该可以将响应类型转换为类合同了吧?
    • 我想我可以使用 Postman 之类的工具检查我的 API 响应,然后处理原始响应。
    • REST中最常见的故障之一是资源被认为是返回类型,即not the case!客户端和服务器应该使用内容类型协商来就既理解又支持的表示格式达成一致。其他所有内容都需要带外信息(在外部文档中或其他),并且可能由于自定义或扩展或由于缺乏对该语法的一般支持而导致以后的互操作性问题。
    猜你喜欢
    • 1970-01-01
    • 2019-12-17
    • 1970-01-01
    • 2018-11-03
    • 1970-01-01
    • 1970-01-01
    • 2013-09-28
    • 1970-01-01
    • 2014-08-10
    相关资源
    最近更新 更多