【问题标题】:Returning BadRequest from WebApi Custom method从 WebApi 自定义方法返回 BadRequest
【发布时间】:2018-09-06 00:18:50
【问题描述】:

在此处使用 .net core web api。

我的 api 中有一个端点:

[HttpPost("data")]
public async Task<IActionResult> PostData(List<string> udata)
{
 JArray sets = new JArray();
 try
 {
    sets = Helper.GetData(udata);

 }
 catch (Exception e)
 {
   return StatusCode(500, e.Message);
 }
}

在上面,我在我的助手“GetData”中调用了一个自定义方法,它完成了所有的处理和计算。为了使 Api 控制器干净,我将所有处理移至此辅助方法。

下面是我的助手类:

public static class Helper
{
    public static BadRequestObjectResult GetMessage(string message)
    {
       return new BadRequestObjectResult(message);
    }

  public static JArray GetData(List<string> udata)
  {
      if(udata == null)
         return  GetMessage("Data is null");

      //do some processing and calclulations here
      //return BadRequest if some issue

   }
 } 

如果有一些处理问题或某些数据不符合预期或其他一些问题,我想抛出 BadRequest。为此,我制作了一个自定义方法来执行“BadRequestObjectResult”。

现在我的问题是,如果 GetData 出现问题,它不会返回到我的 api 或退出我的循环。它只是继续下一条语句。

我知道在退回此文件时存在一些问题,但无法找到问题所在。

谁能指出正确的处理方法?

【问题讨论】:

  • 为什么要GetData 返回JArray?让它返回IActionResult
  • @CamiloTerevinto 在处理和计算之后我希望 GetData 方法返回一个 JArray,这是我的角度 ui 预期的结果
  • Emh... 不,您的 Angular 需要 JSON 结果,JArray 只是 JSON.NET 名称。只需返回new JsonResult(yourData) 并完成
  • 与您的问题不严格相关,但是,您有这个 GetMessage 方法而不是 return BadRequest("Data is null"); 是否有特殊原因?
  • @ChrisPratt 我想保持我的 Api 干净并将所有处理代码移动到通用帮助程序类。在我的辅助类方法中,如果发生错误,我想抛出辅助类中不可用的 BadRequest,因为它不是从控制器库继承的。因此,我创建了自定义消息方法。

标签: c# asp.net-core asp.net-core-webapi


【解决方案1】:

我的建议是从您的 Helper 类中抛出一个异常,并从您的 PostData 方法中处理它。比如……

您可以抛出 ArgumentException 并从您的 API 方法中显式捕获它。

public static class Helper
{

  public static JArray GetData(List<string> udata)
  {
      if(udata == null)
         throw new ArgumentException("Data is null");

      //do some processing and calclulations here
      //throw ArgumentException if there is an issue

   }
 } 

[HttpPost("data")]
public async Task<IActionResult> PostData(List<string> udata)
{
 JArray sets = new JArray();
 try
 {
    sets = Helper.GetData(udata);
    return Ok(sets);
 }
 catch (ArgumentException e)
 {
   return BadRequest(e.Message);
 }
}

这样您就可以只担心控制器的返回代码,而您的 Helper 方法只关心输入并且不会返回专门用于控制器的内容。如果您想在其他地方使用 Helper 类,这种方式会更加灵活。

这也将满足您在遇到错误结果时停止处理的要求,因此一旦遇到错误结果,结果集就会被丢弃并发出 BadRequest 响应。

【讨论】:

  • 感谢这项工作。但是有一个问题,我们应该在这里提出 ArgumentException 还是 WebException。由于它是一个 api,因此它是一个适当的例外。
  • 任一类异常都可以工作,但由于异常是在方法的参数上引发的,我会说 ArgumentException 在这种情况下是更具描述性的选择。
猜你喜欢
  • 1970-01-01
  • 2012-07-31
  • 1970-01-01
  • 2015-10-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多