【问题标题】:Same REST endpoint returning different Error Response Objects相同的 REST 端点返回不同的错误响应对象
【发布时间】:2017-07-06 22:49:22
【问题描述】:

我的客户端应用程序是 REST Endpoint 的消费者,它生成 JSON 响应,可以针对不同场景返回具有不同结构的错误响应;

错误 1

{ 
    "errorCode" : "XXXX"
    "errorMessage" : "Validation Failed"
}//Note the lack of higher order key here; it's flat

错误 2

{
  "apiError" : {
    "errorCode" : "XXXX"
    "errorMessage" : "Validation Failed"
  }
}//Note "apiError" is an object 

错误 3

{
  "apiError" : [{
    "errorCode" : "XXXX"
    "errorMessage" : "Validation Failed"
  }]
}//Note "apiError" is a Collection 

正如我们在上面看到的,很少有错误响应具有相同的键但具有不同的返回类型;

“errorCode”嵌入在不同的键中,也不会与 JSON 响应全局出现在同一级别。

我对如何处理这种情况有点不知所措?是否有任何设计模式或解决方法?

感谢一些指导。

【问题讨论】:

  • 对于相同的请求负载?
  • @Amit Kumar Ghosh - 是的......所有情况下的请求结构都是相同的......
  • @Divs 你是在使用RestTemplate 来消耗这些资源吗?
  • 您实际上使您的客户更加困难,因为他们将不得不关闭 Error1 中显示的 errorCode 和其他错误类型中显示的 apiError。您需要的是一个返回 apiError 类型对象数组的键
  • 我的应用程序是客户端应用程序...它是消费者,而不是生产者。

标签: json rest design-patterns spring-boot response


【解决方案1】:

没有“标准”的方法来处理这个问题,但通常在这种情况下你应该做的是阅读 API 的文档。

一个好的 API 可能对每种类型的错误使用相同的 json 格式,但如果他们不这样做,他们至少应该记录它。一个好的 API 可能还会为每种错误类型使用不同的媒体类型(因此您可以检查 Content-Type 以找出如何解析错误消息)。

可能是每种类型的错误发出时的 API 文档。但是,如果这些都不能指导您以更好的方式以一般方式处理这些类型的错误,您可能只需要查看响应正文并根据提供给您的内容决定如何解析它。

【讨论】:

    【解决方案2】:

    在设计restful API时,需要使用http状态码。这个有相关资料link.

    示例响应如下。

    成功场景(一个或多个场景);

    {
        "errors": null,
        "results": [{
            "key": "value"
        }]
    }
    

    错误场景;

    {
        "errors": [{
            "code": "ERR-500",
            "message": "Error text"
        }],
        "results": null
    }
    

    多个错误场景;

    {
        "errors": [{
            "code": "ERR-500",
            "message": "Error text"
        },{
            "code": "ERR-403",
            "message": "Error2 text"
        }],
        "results": null
    }
    

    【讨论】:

    • 问题提到我的应用程序是消费者而不是生产者。
    猜你喜欢
    • 1970-01-01
    • 2017-03-11
    • 2017-10-15
    • 2022-08-21
    • 1970-01-01
    • 1970-01-01
    • 2015-09-23
    • 2012-06-22
    • 1970-01-01
    相关资源
    最近更新 更多