NOTE: ASP.NET Web API doesn’t have inherent support for Accept-Encoding header.

Let’s assume we have the following controller which is returning 3 different HttpContents: StringContent, StreamContent & ObjectContent.

public class AcceptEncodingTestsController : ApiController
    {
        [HttpGet]
        public HttpResponseMessage GetStringContent()
        {
            HttpResponseMessage response = new HttpResponseMessage();
            response.Content = new StringContent("Hello World!");

            return response;
        }

        [HttpGet]
        public HttpResponseMessage GetStreamContent()
        {
            HttpResponseMessage response = new HttpResponseMessage();
            response.Content = new StreamContent(new FileStream(@"D\Sample.txt", FileMode.Open));
            response.Content.Headers.ContentType = new MediaTypeHeaderValue("text/plain");
            return response;
        }

        [HttpGet]
        public Customer GetCustomer() // the return value is actually converted to ObjectContent
        {
            return new Customer() { Id = 100, DateOfBirth = new DateTime(1975, 4, 3) };
        }
    }

Encoding handler:

public class EncodingDelegateHandler : DelegatingHandler
    {
        protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            return base.SendAsync(request, cancellationToken).ContinueWith<HttpResponseMessage>((responseToCompleteTask) =>
            {
                HttpResponseMessage response = responseToCompleteTask.Result;

                if (response.RequestMessage.Headers.AcceptEncoding != null &&
                    response.RequestMessage.Headers.AcceptEncoding.Count > 0)
                {
                    string encodingType = response.RequestMessage.Headers.AcceptEncoding.First().Value;

                    response.Content = new CompressedContent(response.Content, encodingType);
                }

                return response;
            },
            TaskContinuationOptions.OnlyOnRanToCompletion);
        }
    }

    public class CompressedContent : HttpContent
    {
        private HttpContent originalContent;
        private string encodingType;

        public CompressedContent(HttpContent content, string encodingType)
        {
            if (content == null)
            {
                throw new ArgumentNullException("content");
            }

            if (encodingType == null)
            {
                throw new ArgumentNullException("encodingType");
            }

            originalContent = content;
            this.encodingType = encodingType.ToLowerInvariant();

            if (this.encodingType != "gzip" && this.encodingType != "deflate")
            {
                throw new InvalidOperationException(string.Format("Encoding '{0}' is not supported. Only supports gzip or deflate encoding.", this.encodingType));
            }

            // copy the headers from the original content
            foreach (KeyValuePair<string, IEnumerable<string>> header in originalContent.Headers)
            {
                this.Headers.TryAddWithoutValidation(header.Key, header.Value);
            }

            this.Headers.ContentEncoding.Add(encodingType);
        }

        protected override bool TryComputeLength(out long length)
        {
            length = -1;

            return false;
        }

        protected override Task SerializeToStreamAsync(Stream stream, TransportContext context)
        {
            Stream compressedStream = null;

            if (encodingType == "gzip")
            {
                compressedStream = new GZipStream(stream, CompressionMode.Compress, leaveOpen: true);
            }
            else if (encodingType == "deflate")
            {
                compressedStream = new DeflateStream(stream, CompressionMode.Compress, leaveOpen: true);
            }

            return originalContent.CopyToAsync(compressedStream).ContinueWith(tsk =>
            {
                if (compressedStream != null)
                {
                    compressedStream.Dispose();
                }
            });
        }
    }

Register the handler:

config.MessageHandlers.Add(new EncodingDelegateHandler());

With the above example you should see that all the 3 types of contents are compressed via the encoding handler.

Opt-out model:

There is  an attribute called ApiExplorerSettings which enables you to opt-out controllers and actions from showing up on the help page. Examples below:

[ApiExplorerSettings(IgnoreApi = true)]

    public class ValuesController : ApiController

    {

        // GET api/values

        public IEnumerable<string> Get()

        {

            return new string[] { "value1", "value2" };

        }

        // GET api/values/5

        public string Get(int id)

        {

            return "value";

        }

    }

    public class AbcController : ApiController

    {

        [ApiExplorerSettings(IgnoreApi = true)]

        public IEnumerable<string> Get()

        {

            return new string[] { "value1", "value2" };

        }

        // GET api/values/5

        public string Get(int id)

        {

            return "value";

        }

    }

Opt-in model:

With opt-in model, you need not decorate your controllers/actions with attributes. You could have all the logic in one central place.

public class OptInApiExplorer : ApiExplorer

    {

        public OptInApiExplorer(HttpConfiguration config)

            : base(config)

        {

        }

        public override bool ShouldExploreController(string controllerVariableValue, HttpControllerDescriptor controllerDescriptor, IHttpRoute route)

        {

            // show help for ValuesController only

            if (controllerDescriptor.ControllerType == typeof(ValuesController))

            {

                return true;

            }

            return false;

        }

        // I overrode this method just to demonstrate the presence of this overridable behavior

        // For the current discussion, i am going to leave it as it is.

        public override Collection<HttpMethod> GetHttpMethodsSupportedByAction(IHttpRoute route, HttpActionDescriptor actionDescriptor)

        {

            return base.GetHttpMethodsSupportedByAction(route, actionDescriptor);

        }

    }

Replace the service on configuration:

config.Services.Replace(typeof(IApiExplorer), new OptInApiExplorer(config));

Currently the approach for enabling buffered/streamed mode of receiving data is different between SelfHost and WebHost scenarios and also the capabilities are also different.

There is a service called IHostBufferPolicySelector on HttpConfiguration, which as the name indicates is for the purpose of tuning your requests to be enable buffered/streamed mode. Currently there is only one implementation of it called WebHostBufferPolicySelector which as its name indicates is only for Web Host scenarios.

Web Host

public class CustomWebHostBufferPolicySelector : WebHostBufferPolicySelector

    {

        // Check incoming requests and modify their buffer policy

        public override bool UseBufferedInputStream(object hostContext)

        {

            System.Web.HttpContextBase contextBase = hostContext as System.Web.HttpContextBase;

            if (contextBase != null

                && contextBase.Request.ContentType != null

                && contextBase.Request.ContentType.Contains("multipart"))

            {

                // we are enabling streamed mode here

                return false;

            }

            // let the default behavior(buffered mode) to handle the scenario

            return base.UseBufferedInputStream(hostContext);

        }

        // You could also chnage the response behavior too...but for this example, we are not

        // going to do anything here...I overrode this method just to demonstrate the availability

        // of this method.

        public override bool UseBufferedOutputStream(System.Net.Http.HttpResponseMessage response)

        {

            return base.UseBufferedOutputStream(response);

        }

    }

Register this service in HttpConfiguration.

config.Services.Replace(typeof(IHostBufferPolicySelector), new CustomWebHostBufferPolicySelector());

No implementation of IHostBufferPolicySelector currently. However, one could enable Streamed mode in Self Host by doing the following:

selfHostConfiguration.TransferMode = System.ServiceModel.TransferMode.StreamedRequest;

You can visit this documentation for more details about the TransferMode.

As you can see currently you have the ability of enabling streamed/buffered mode on a per-request basis in Web Host, where as in Self Host scenarios, you would need to enable it for the whole service.

What is Chunked Transfer Encoding: This represented by the header “Transfer-Encoding: chunked” indicates that a Request/Response does not know the Content Length of the body that it is going to generate upfront. This header enables to send data the moment it is available instead of the normal flow that a client/service does, which is to buffer the entire content and then send it. Since buffering big content is expensive, this header could be used to send data in chunks the moment it is ready.

        
[1] – By “Response Buffering at Service”, I mean the buffering ability provided by the hosting layers (ex: IIS/ASP.NET in case of Web Host scenarios).

One of the main things that we try to do is to not double buffer the response content if we already know that a content has been buffered in the upper layers of the  stack. (Example: Action is returning a HttpResponseMessage having a StringContent). We depend on the Content-Length header of the response content to figure out if a content has already been buffered or not. For example, If you notice the above table, all the content types for which we know the Content Length, we do not buffer again.

ObjectContent is Buffered : This is important because it enables to provide a good user experience in case when MediaTypeFormatters throw exceptions while writing to a stream.

NOTE: I deliberately left out these details for Self Host scenarios, because the above behaviors are not in symmetry with Self Host. I will create a new post in future for Self Host specifically.

Have fun!.  

A notable difference between the following currently in development diagram and the RC version stack is the addition of a nice feature: Ability for having route-specific message handler pipelines.

Henrik provides a nice overview of this feature over here.

(click the image to get a larger image) 

Have fun!

NOTE: This stack represents the Release Candidate(RC) version only. It does not represent the stack that is part of our ongoing development.

(click the image to get a larger image)

If you have gone through my post ASP.NET MVC4 WebAPI Stack Diagram, you will notice that there is a block (green color) which says “In memory client-host using no network (HttpMessageInvoker/HttpClient)”. This post is about that block and how you could do in-memory testing without using the network at all.

Some Pros and Cons of using In-memory testing:

Pros:

- Tests run very fast as there is no additional overhead of setting up port etc. Since these tests run very fast, you could write integration tests itself, but still expect the kind of performance that you would see in your unit tests.  

- Since HttpServer is the common layer for Web Host and Self Host layers, you could test your functionality independent of the hosting layers. (Of course, if you are testing a feature which is very specific to a host, using a real host would make sense.)

Cons:

- Cannot use the awesome tool Fiddler to capture the Request/Response messages!. Fiddler is a great tool for debugging purposes where you can exactly see how your request/response messages look like over the wire. Since we are testing everything in-memory, we would loose this capability.

- When doing in-memory testing, the request and response contents are basically stream contents backed up by buffered streams (example: in my example in this post, you would notice that the method ConvertToStreamContent() uses MemoryStream). This might not be ideal in some situations where you might be expecting a non-buffered stream.

- Error response messages behavior is currently different between Web Host and Self Host due to some bugs.

In view of some of the above Pros & Cons, you should be a better judge of whether in-memory kind of testing works for you or not.

Following is an example of a typical in-memory test:

Some things to consider while writing an in-memory test:

- Client to use: You can use HttpClient or HttpMessageInvoker. In fact HttpClient derives from HttpMessageInvoker. HttpMessageInvoker is lightweight compared to HttpClient, so I usually like to use it in my testing.

- In a real user scenario, data would be sent in a serialized format over the wire and its later deserialized at the client/service. For example, in our current case, data is serialized/deserialized by MediaTypeFormatters. Since we are doing in-memory testing, there are some caveats that we need to take care of.

Important: For example, the ParameterBinding stage tries to read the incoming request’s content using the HttpContent extension called “ReadAsAsync<>()” . This extension has internal checks to see if the request’s content is an ObjectContent or not. If its is an ObjectContent, then it does NOT try to read the request content stream again to deserialize the data. This is a cause of concern for us here since we are doing in-memory testing and the request/response contents could be of ObjectContent type, which means that we will not go through the MediaTypeFormatters’ ReadFromStream or WriteToStream methods.

To overcome this problem, we can create a Message Handler which causes the in-memory objects to be serialized into a stream of bytes in order to make the MediaTypeFormatters to take part in the serialization/deserialization process. In the following example code, you should see the message handler InMemoryHttpContentSerializationHandler doing that.

(click the image to get a larger image)

Here I am using XUnit framework for testing. I hope you can relate the following code to your test framework:

public class OrdersController : ApiController
{
    [HttpPost]
    public Order CreateOrder(Order order)
    {
        return order;
    }
}

public class InMemoryTesting
{
    [Fact]
    public void CreateOrderTest()
    {
        string baseAddress = "https://dummyname/";

        // Server
        HttpConfiguration config = new HttpConfiguration();
        config.Routes.MapHttpRoute("Default", "api/{controller}/{action}/{id}", 
                                    new { id = RouteParameter.Optional });
        config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;

        HttpServer server = new HttpServer(config);

        // Client
        HttpMessageInvoker messageInvoker = new HttpMessageInvoker(new InMemoryHttpContentSerializationHandler(server));

        //order to be created
        Order requestOrder = new Order() { OrderId = "A101", OrderValue = 125.00, OrderedDate = DateTime.Now.ToUniversalTime(), ShippedDate = DateTime.Now.AddDays(2).ToUniversalTime() };

        HttpRequestMessage request = new HttpRequestMessage();
        request.Content = new ObjectContent<Order>(requestOrder, new JsonMediaTypeFormatter());
        request.RequestUri = new Uri(baseAddress + "api/Orders/CreateOrder");
        request.Headers.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));
        request.Method = HttpMethod.Post;

        CancellationTokenSource cts = new CancellationTokenSource();

        using (HttpResponseMessage response = messageInvoker.SendAsync(request, cts.Token).Result)
        {
            Assert.NotNull(response.Content);
            Assert.NotNull(response.Content.Headers.ContentType);
            Assert.Equal<string>("application/xml; charset=utf-8", response.Content.Headers.ContentType.ToString());
            Assert.Equal<Order>(requestOrder, response.Content.ReadAsAsync<Order>().Result);
        }
    }
}

public class InMemoryHttpContentSerializationHandler : DelegatingHandler
{
    public InMemoryHttpContentSerializationHandler()
    {
    }

    public InMemoryHttpContentSerializationHandler(HttpMessageHandler innerHandler)
        : base(innerHandler)
    {
    }

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        // Replace the original content with a StreamContent before the request
        // passes through upper layers in the stack
        request.Content = ConvertToStreamContent(request.Content);

        return base.SendAsync(request, cancellationToken).ContinueWith<HttpResponseMessage>((responseTask) =>
                                                                    {
                                                                        HttpResponseMessage response = responseTask.Result;

                                                                        // Replace the original content with a StreamContent before the response
                                                                        // passes through lower layers in the stack
                                                                        response.Content = ConvertToStreamContent(response.Content);

                                                                        return response;
                                                                    });
    }

    private StreamContent ConvertToStreamContent(HttpContent originalContent)
    {
        if (originalContent == null)
        {
            return null;
        }

        StreamContent streamContent = originalContent as StreamContent;

        if (streamContent != null)
        {
            return streamContent;
        }

        MemoryStream ms = new MemoryStream();

        // **** NOTE: ideally you should NOT be doing calling Wait() as its going to block this thread ****
        // if the original content is an ObjectContent, then this particular CopyToAsync() call would cause the MediaTypeFormatters to 
        // take part in Serialization of the ObjectContent and the result of this serialization is stored in the provided target memory stream.
        originalContent.CopyToAsync(ms).Wait();

        // Reset the stream position back to 0 as in the previous CopyToAsync() call,
        // a formatter for example, could have made the position to be at the end after serialization
        ms.Position = 0;

        streamContent = new StreamContent(ms);

        // copy headers from the original content
        foreach (KeyValuePair<string, IEnumerable<string>> header in originalContent.Headers)
        {
            streamContent.Headers.TryAddWithoutValidation(header.Key, header.Value);
        }

        return streamContent;
    }
}

Have fun!

7. Up until now, we have seen how the Accept and Request Content-Type headers play a role in Conneg algorithm’s decision making process. There is one more way by which Conneg algorithm decides about the Response’s media type and formatter. It is called MediaTypeMapping. Every MediaTypeFormatter has a collection of these mappings in it.

MediaTypeMapping provides a way for the user to add some custom logic and decide whether they would want the formatter to take part in writing the Response. This is different from the default way of just matching media type values(like “application/xml”) present on the Accept and Request Content-Type headers and making decisions.

MediaTypeMapping provides a greater control.

Example:

Here I am creating a media type mapping which checks if the Request has a “Browser” header called “Internet Explorer”. If it finds the header, then it would inform the Conneg algorithm that it’s a full match and that the media type formatter having this media type mapping is ready to write the response.

public class BrowserMediaTypeMapping : MediaTypeMapping
{
    public BrowserMediaTypeMapping() :
        base(new MediaTypeHeaderValue("application/xml"))
    {
    }

    /// <summary>
    /// NOTE: do NOT use this. It was too late for us to remove this method in Beta.
    /// It will be gone in RC though.
    /// </summary>
    /// <param name="request"></param>
    /// <returns></returns>
    protected override double OnTryMatchMediaType(HttpRequestMessage request)
    {
        throw new NotImplementedException();
    }

    protected override double OnTryMatchMediaType(HttpResponseMessage response)
    {
        double match = 0.0; //no match

        //get the Request object associated with this Response
        HttpRequestMessage request = response.RequestMessage;

        //check the Request's headers for the Browser header
        IEnumerable<string> values = null;
        string browser = null;
        if (request.Headers.TryGetValues("Browser", out values))
        {
            browser = values.First();
        }

        if (browser != null && browser.ToLowerInvariant() == "internetexplorer")
        {
            match = 1.0; // full match
        }

        return match;
    }
}

As I mentioned earlier, each MediaTypeFormatter object has a collection of media type mappings available through the MediaTypeMappings property. So, we can add our BrowserMediaTypeMapping object in that collection like below:

public SetupSelfHost()
{
    HttpSelfHostConfiguration config = new HttpSelfHostConfiguration(this.BaseAddress);
    config.Routes.MapHttpRoute("Default", "{action}", new { controller = "MappingTests" });

    config.Formatters.XmlFormatter.MediaTypeMappings.Add(new BrowserMediaTypeMapping());

    server = new HttpSelfHostServer(config);
    server.OpenAsync().Wait();
}

NOTE: In the above code snippet, I am just adding the mapping to the existing default formatter collection which has the formatters (in this order): JsonMediaTypeFormatter, XmlMediaTypeFormatter & FormUrlEncodedMediaTypeFormatter.

Now let’s see an example of how the Conneg algorithm behaves when a Request has the “Browser” header:

Request:

GET https://kirandev10:9090/MappingTests/GetString HTTP/1.1
Browser: InternetExplorer
Host: kirandev10:9090
Connection: Keep-Alive

Response:

HTTP/1.1 200 OK
Content-Length: 60
Content-Type: application/xml
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 26 Feb 2012 23:58:43 GMT

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

In the above scenario, a GET request is sent without any Accept header. Usually if this kind of request is sent, Conneg algorithm would pick the 1st formatter in the list of formatters and that would be the JsonMediaTypeFormatter.

But, since the request has a “Browser” header with the value “Internet Explorer”, the XmlMediaTypeFormatter’s BrowserMediaTypeMapping checks this and responds to the Conneg algorithm by giving it a full match.

Hence we are seeing the Response in a “application/xml” format instead of the default “application/json” format.

As you can imagine, MediaTypeMapping provides full power to you to inspect incoming request and make a decision of whether to participate in a response or not.

By default, ASP.NET MVC4 Beta Web API ships with 4 built-in media type mappings. They are:

QueryStringMapping

RequestHeaderMapping

UriPathExtensionMapping

MediaRangeMapping

I will discuss more about these individually in my later posts.

What happens when multiple formatters match an incoming request’s criteria? Which one does the Conneg algorithm choose?

During the Conneg algorithm run, based on bunch of criteria like the Request Accept header, Content-Type header, MediaTypeMapping etc, there is always a possibility that more than one formatter could indicate its availability in writing the Response. As you can imagine, the Conneg algorithm has to choose only one formatter in the end.

The Default Conneg algorithm has the following precedence order to select the final formatter:

1. Formatter match based on Media Type Mapping.

2. Formatter match based on Request Accept header's media type.

3. Formatter match based on Request Content-Type header's media type.

4. Formatter match based on if it can serialize the response data’s Type.

In spite of all this, as mentioned in “Point 6.”, if a user decides to always send a Response in a particular media type, Conneg algorithm will honor it and will not override it.

This is my first blog post…Yay! .

In this blog post, I am going to describe about the Default Content Negotiation Algorithm that gets shipped as part of ASP.NET MVC4 Beta. The Web API provides a lot of nice features with which you can build RESTful services. For more details, you can look at the release notes here.

Throughout the rest of this post, I will refer to Content-Negotiation simply as Conneg.

I use the tool called Fiddler to capture the requests and responses. I find it very useful for debugging purposes.

1. If a Request message is sent with an Accept header, Conneg algorithm will use the Accept header to decide about the Response media type and the MediaTypeFormatter to write.
This should make sense to you as here the client is asking for a response in a specific format.

Example:

Request:

GET https://kirandev:9090/DefaultConNegAlgorithmTests/GetData HTTP/1.1
Accept: application/xml
Host: kirandev10:9090
Connection: Keep-Alive

Response:

HTTP/1.1 200 OK
Content-Length: 60
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 21:03:47 GMT

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

2. If a Request message is sent with NO Accept header and with a Content-Type header (let’s say when you are using POST to post content to the server),  Conneg algorithm will use the Content-Type header to decide about the Response media type and the MediaTypeFormatter to write.

Here the Conneg algorithm uses the best-effort approach to judge which format the client could understand. Since here the client was able to post content in a particular format(let’s say ‘application/xyz’), Conneg algorithm deduces that the Client could probably understand the Response also in the same format(‘application/xyz’).

Example:

Request:

POST https://kirandev:9090/DefaultConNegAlgorithmTests/PostData HTTP/1.1
Content-Type: application/xml
Host: kirandev10:9090
Content-Length: 60
Expect: 100-continue
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

Response:

HTTP/1.1 200 OK
Content-Length: 60
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 21:12:34 GMT

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

3. If a Request message is sent with an Accept header and also a Content-Type header, Conneg algorithm will use the Accept header to decide about the Response media type and the MediaTypeFormatter to write.
This should make sense to you as here the Client is asking for a Response in a specific format.

Example:

Request:

POST https://kirandev10:9090/DefaultConNegAlgorithmTests/PostData HTTP/1.1
Accept: application/xml
Content-Type: application/json
Host: kirandev10:9090
Content-Length: 7
Expect: 100-continue
Connection: Keep-Alive

"Hello"

Response:

HTTP/1.1 200 OK
Content-Length: 60
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 21:09:59 GMT

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

4. A variation to “Point 3.” above: If a Request message is sent with an Accept header and also a Content-Type header, then Conneg algorithm will use the Accept header to decide about the Response media type and the MediaTypeFormatter to write. 

Now, if the Conneg algorithm wasn’t able to find a formatter for the supplied media type in the Accept header, then it uses the best-effort approach and uses the Content-Type header to decide about the Response media type and the MediaTypeFormatter to write.

Example:

Request:

POST https://kirandev:9090/DefaultConNegAlgorithmTests/PostData HTTP/1.1
Accept: application/nonexisting
Content-Type: application/xml
Host: kirandev10:9090
Content-Length: 60
Expect: 100-continue
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

Response:

HTTP/1.1 200 OK
Content-Length: 60
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 21:15:50 GMT

<?xml version="1.0" encoding="utf-8"?><string>Hello</string>

5. For ALL the above scenarios from 1 to 4, if the Conneg algorithm wasn’t able to find a suitable formatter to write the Response, then by default it would send back content using the 1st formatter in the collection of MediaTypeFormatters present on the Configuration object.

Example:

Request:

GET https://kirandev10:9090/DefaultConNegAlgorithmTests/GetData HTTP/1.1
Accept: application/nonexisting
Host: kirandev10:9090
Connection: Keep-Alive

Response(Here the 1st formatter in my list is a JsonMediaTypeFormatter and hence the response is in Json format):

HTTP/1.1 200 OK
Content-Length: 7
Content-Type: application/json; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 21:25:40 GMT

"Hello"

6. If for a particular reason, a user needs to always send a Response in a specific format and NOT caring about the Content Negotiation, we have support for it. For example, in the following piece of code, the Action called “GetOrder” is specifically setting the media type to be “application/xml”. So, Web API honors this and will not let the Conneg algorithm to overwrite it irrespective of the Request’s Accept header media type.

public class OrdersController : ApiController
    {
        public HttpResponseMessage GetOrder()
        {
            Order order = new Order();
            order.Id = "A100";
            order.OrderedDate = DateTime.Now;
            order.OrderTotal = 150.00;

            HttpResponseMessage<Order> response = new HttpResponseMessage<Order>(order, 
                        new MediaTypeHeaderValue("application/xml"));

            return response;
        }
    }

Example:

Request:

GET https://kirandev:9090/DefaultConNegAlgorithmTests/GetOrder HTTP/1.1
Accept: application/json
Host: kirandev10:9090
Connection: Keep-Alive

Response:

HTTP/1.1 200 OK
Content-Length: 253
Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 25 Feb 2012 22:36:22 GMT

<?xml version="1.0" encoding="utf-8"?><Order xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"><Id>A100</Id><OrderedDate>2012-02-25T14:36:21.4774615-08:00</OrderedDate><OrderTotal>150</OrderTotal></Order>

I hope you guys find this post useful. I will be posting more content in near future. Keep playing with our bits!

Also there is a forum regarding ASP.NET Web API over here. It’s very active and post any questions that you might have.