如何在 Web API 控制器上返回 Json 对象答案

【问题标题】：How to return Json object on Web API Controller如何在 Web API 控制器上返回 Json 对象
【发布时间】：2013-01-09 09:22:27
【问题描述】：

我在我的 asp.net 控制器上使用以下代码在我的 javascript 上的 Ajax 上返回 Json 对象

public JsonResult myMethod()
{
    // return a Json Object, you could define a new class
    return Json(new
    {
        Success = true, //error
        Message = "Success" //return exception
    });
}

jQuery-Ajax：

$.ajax({
    type: "POST",
    url: url_ ,
    data: search,
    success: function(data) {   
        //Show Json Properties from Controller ( If Success == false show exception Message from controller )
        if (data.Success)  
        {
            alert(data.Message); //display success 
        }
        else
        {
            alert(data.Message) //display exception
        }
    },
    error: function(XMLHttpRequest, textStatus, errorThrown) {
        alert("error: " + XMLHttpRequest.responseText);
    },
    dataType: 'json'
});

如何在 Web Api Controller 上做到这一点？

你能给我一些例子或网址作为参考。

感谢和问候

【问题讨论】：

标签： jquery jquery-mobile asp.net-mvc-4 visual-studio-2012 asp.net-web-api

【解决方案1】：

ASP.NET Web API 的工作原理略有不同。您应该只返回一个实体（或一组实体），内容协商机制以客户请求的格式将其返回给客户。您可以在此处阅读有关内容协商的更多信息：

Everything you want to know about ASP.NET Web API content negotiation

您当然可以通过返回HttpResponseMessage 来绕过内容协商。在这种情况下，您需要自己将对象序列化为 JSON（这种方法的基础知识也在上面提到的文章中进行了描述）。

【讨论】：

在我看来，这既不是 Web API 的哲学，也不是内容协商的哲学。返回任意类型是一种可能的使用 Web API 的特殊方式，但它有很多潜在的陷阱。内容协商是客户端声明它能够处理哪些媒体类型并且服务器尝试适应客户端偏好的机制。重点与说客户端请求格式 X 完全不同。您仍然可以执行 conneg 并返回 HttpResponseMessage。
@DarrelMiller 总的来说，我同意，而且我现在不会像 4 个月前那样写这个答案——很好，你的答案是被接受的。我相信有些人发现我的帮助主要是因为链接下提供的内容。
希望更多的人在开始使用 WebAPI 后会意识到，仅仅返回对象的最初吸引力并不像看起来那么有用。
根据 Web Api 2 及其 IHttpActionResult，tpeczek 的答案似乎是正确的。

【解决方案2】：

如果你自己创建一个新的 HttpContent 类来传递 JSON，比如...

 public class JsonContent : HttpContent {

    private readonly MemoryStream _Stream = new MemoryStream();
    public JsonContent(object value) {

        Headers.ContentType = new MediaTypeHeaderValue("application/json");
        var jw = new JsonTextWriter( new StreamWriter(_Stream));
        jw.Formatting = Formatting.Indented;
        var serializer = new JsonSerializer();
        serializer.Serialize(jw, value);
        jw.Flush();
        _Stream.Position = 0;

    }
    protected override Task SerializeToStreamAsync(Stream stream, TransportContext context) {
        return _Stream.CopyToAsync(stream);
    }

    protected override bool TryComputeLength(out long length) {
        length = _Stream.Length;
        return true;
    }
}

那你就可以了，

      public HttpResponseMessage Get() {
            return new HttpResponseMessage() {
                Content = new JsonContent(new
                {
                    Success = true, //error
                    Message = "Success" //return exception
                })
            };
        }

就像你对 JsonResult 所做的那样。

【讨论】：

为什么不使用 Web API 的默认序列化行为，直接返回你的类型，让框架处理序列化？
@TedNyberg 因为有时控制您的电汇格式非常重要。让序列化程序为您做出决定可以使您依赖于该序列化程序及其配置。与 XML 相比，这对 Json 来说不是问题，但它仍然可能是一个问题。
在这个答案中包含一个如何使用“默认序列化行为”的例子可能会很好（我自己并不完全确定，是Request.CreateResponse(....,myJsonObject)吗？）
@Assimilater 这是几种方法之一。您也可以只从控制器方法返回本机 CLR 对象，格式化程序将对其进行序列化。
@DarrelMiller 啊，我明白了。从搜索看来，这本身就是另一个问题（已回答here）

【解决方案3】：

在阅读了 tpeczek 的回答、Darrel Miller 的回答以及他们在 tpeczek 的回答中的评论对话后，我想获得更多关于何时或为什么要使用 Web Api 及其内容协商机制的指导。 tpeczek 的链接内容丰富且有用，但我发现了其他一些文章，它们更倾向于将 Web Api（及其内容协商）的使用与返回 JsonResult 的普通 MVC 4 控制器操作进行比较。以下是我发现对做出这样的决定有用的那些。其中一位作者得出结论，他更喜欢使用普通的 MVC 4 控制器，而另一位作者更喜欢使用 Web Api 控制器：

Building a Public HTTP API for Data

我认为上述作者的帖子需要更正。他在那里提到，

"...每个以 'Get' 开头的 [Controller] 方法都会自动与 GET 动词相关联。听起来很棒吗？它是，但它也是意味着您不能有两个名称以“Get”开头的方法相同的控制器类。”

根据this answer，如果您指定ActionName 属性，您确实可以在同一个控制器中拥有多个“Get”方法。现在这是第二个帖子：

ASP.NET Web API vs. ASP.NET MVC “APIs”

【讨论】：