关于 WebApi 返回值的探究

关于 WebApi 返回值的探究

写这篇文章的原因主要是，工作时间长了，各种乱七八糟的项目和框架都见识过了，前端后端都写过，怎么说也算得上是全栈了，见过一堆不规范的代码，特别是这个webapi的返回值问题

这里以asp.net core为例，不讨论MVC的情况

IActionResult 和 ActionResult

这里主要是想写一下这俩的区别，我也容易忘

• IActionResult：根据官方文档，这个返回值主要是用于多个返回类型，说白了就是能返回object
• ActionResult<T>：这个有一个泛型，一看就知道这个是限制返回类型的

那么说下我的使用习惯，如果需要返回值，选ActionResult<T>，无返回值则选IActionResult

封装统一返回值

大部分都长这个样子

{
    code: null,
    status: null,
    message: null,
    data: null
}

就我见过的代码而言，这里算是个重灾区，我是不太明白为什么都喜欢搞这个，java的习惯？

统一返回值存在的问题

• 首先是后端代码的可读性，都这么写返回值了，那么肯定不是ActionResult，都偷懒写IActionResult了，鬼知道这个函数返回什么，过一段时间你还记得住？
  如果这个函数还返回别的类型呢？那我后端强类型的意义是什么，跟写js一样，你这后端还是强类型？
  你说这是统一返回值，那如果你这代码还没到中间件就异常了呢？你还统一吗？

• 然后再来说说前端的问题，上面说了鬼知道这个返回值是什么
  前端还要先先等你写好这个接口，再试一遍这个接口，然后再从这一坨返回值里面一层一层空值判断取数据，对不同类型的返回值做处理，你这前后端分离个鬼
  js还好说，如果我的前端是WPF或Blazor呢？json字符串转JObject或者Dictionary然后用索引取数据？这空值处理和数据转换更麻烦
  给这个后端写过一段时间前端我就再也不想看见这一坨东西了，直接重写

总结，不要使用统一返回值，你可以通过中间件给状态码使用不同的返回值，这样前端处理起来也方便
或者给这个统一的返回值加一个泛型，这个也就比ActionResult多套一层，不过这种代码我还没见过呢，都是纯纯的懒狗代码

关于 WebApi 返回值的探究 结束

规范很重要