Web API 2返回文本/简单响应

Question

Really struggling with something I hope people here can help with. I'm writing a RESTful API in Web API 2. Whenever I send a request to this service, the response is consistently being sent with a Content-Type of text/plain . Obviously this is no good, my response needs to be Content-Type of application/json . I've tried a few suggestions that I found from Google but I don't think I'm understanding the whole picture.

Is there something special I need to do in order to have my web service respond with application/json content? Note that I want this to work globally across the whole app, so I'm not after a way to modify a given response and set its content type - I want this to be a default behaviour for the whole web service: If a request contains an Accept header for application/json I want my web service to return that Content-Type instead of text/plain .

Edit to clarify:

My response contains an object called "responseData" that should be serialized into JSON and included in the body. I'm currently putting together my response like this:

HttpResponseMessage response = Request.CreateResponse(HttpStatusCode.OK, responseData);
return response;

responseData is a POCO. This get's correctly serialized as JSON and returned in the response - the only missing part is the Content-Type which is incorrectly set to "text/plain". I could manually change this on every single response I compose, but I'm wanting to configure this on a global level.

Answer 1

OK, assuming that your responseData is a string, the Content-type header will be text/plain when you create the HttpResponseMessage . Doesn't matter what the contents of the string are, since no attempt is made to determine this.

The solution is to create the appropriate Content object for your message, initialized with the media type you're returning:

HttpResponseMessage response = new HttpResponseMessage()
    {
        Content = new StringContent(
                responseData,
                Encoding.UTF8,
                "application/json"
            )
    };

There are other methods that amount to returning a particular object type and letting the API libraries serialize to JSON or XML for you as required. I prefer to let the framework do the work for me where possible, but this is how you'd achieve it with a string you've created yourself.

---

For a strict JSON-only result, remove the XML formatter from the WebAPI configuration and return your POCO.

In App_Start\\WebApiConfig.cs , add the following to the WebApiConfig.Register method:

config.Formatters.Remove(config.Formatters.XmlFormatter);

And for your API:

public class MyObject
{
    public bool result;
    public string reason;
}

public class TestController : ApiController
{
    public MyObject GetData()
    {
        MyObject result = new MyObject { result = "true", reason = "Testing POCO return" };
        return result;
    }
}

I ran this up and requested /api/Test from Chrome, which doesn't even mention application/json in the Accept header. Here are the response headers up until it hits Content-Type :

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8

And the body:

{"result":true,"reason":"Testing POCO return"}

Since I disabled XML it defaulted to JSON.

Answer 2

Add the following to Global.asax file.

protected void Application_Start()
{

JsonSerializerSettings serializerSettings = new JsonSerializerSettings();
serializerSettings.Converters.Add(new IsoDateTimeConverter());
var jsonFormatter = new JsonNetFormatter(serializerSettings);
jsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue("text/html"));
GlobalConfiguration.Configuration.Formatters.Insert(0, jsonFormatter);

}

Answer 3

Another possible source of the issue described is that there may be an authorization redirect in play as was the case for us when one of the engineers thought to re-use user authentication for an api.

This means incoming requests were being redirected to a login page which was the text/html response that couldn't be parsed by ReadAsync<> . A silly mistake to be sure, but not an easy one to spot.

The solution in that case was to remove the user authentication and implement HMAC based authentication for the api.