Request for Comments (RFC) 2616 defines content negotiation as “the process of selecting the best representation for a given response when there are multiple representations available.” RFC also states “this is not called format negotiation, because the alternate representations may be of the same media type, but use different capabilities of that type, be in different languages, etc.” The term negotiation is used because the client indicates its preferences. A client sends a list of options with a quality factor specified against each option, indicating the preference level. It is up to the service, which is Web API in our case, to fulfill the request in the way the client wants, respecting the client preferences. If Web API cannot fulfill the request the way the client has requested, it can switch to a default or send a 406 -Not Acceptable status code in the response. There are four request headers that play a major part in this process of content negotiation:

1. Accept, which is used by a client to indicate the preferences for the media types for the resource representation in the response, such as JSON (application/json) or XML (application/xml).
2. Accept-Charset, which is used by a client to indicate the preferences for the character sets, such as UTF-8 or UTF-16.
3. Accept-Encoding, which is used by a client to indicate the preferences for the content encoding, such as gzip or deflate.
4. Accept-Language, which is used by a client to indicate the preferences for the language, such as en-us or fr-fr.

Content negotiation is not just about choosing the media type for the resource representation in the response. It is also about the language, character set, and encoding. Chapter 3 covered content negotiation related to the media type, in which the Accept header plays a major role. This chapter covers content negotiation related to language, character set, and encoding.

4.1 Negotiating Character Encoding

Simply put, character encoding denotes how characters—letters, digits and other symbols—are represented as bits and bytes for storage and communication. The HTTP request header Accept-Charset can be used by a client to indicate how the response message can be encoded. ASP.NET Web API supports UTF-8 and UTF-16 out of the box. The following are the steps to see the process of character-set negotiation in action.

1. Create a new ASP.NET MVC 4 project with a name of HelloWebApi using the Web API template.
2. Add the Employee class, as shown in Listing 4-1, to the Models folder.

   Listing 4-1.  The Employee Class

   public class Employee
   {
       public int Id { get; set; }
       public string FirstName { get; set; }
       public string LastName { get; set; }
   }
   

3. Modify the Register method in WebApiConfig, in the App_Start folder, as shown in Listing 4-2.

   Listing 4-2.  Supported Encodings

   public static class WebApiConfig
   {
       public static void Register(HttpConfiguration config)
       {
           config.Routes.MapHttpRoute(
               name: "DefaultApi",
               routeTemplate: "api/{controller}/{id}",
               defaults: new { id = RouteParameter.Optional }
           );
    
           foreach (var encoding in config.Formatters.JsonFormatter.SupportedEncodings)
           {
               System.Diagnostics.Trace.WriteLine(encoding.WebName);
           }
       }
   }
   

4. Rebuild the solution and press F5 to run the application from Visual Studio. You will see that the code prints utf-8 followed by utf-16 in the Output window of Visual Studio. UTF-8 and UTF-16 are the character encodings supported by ASP.NET Web API out of the box. UTF-8 is the default.
5. Add a new empty API controller with the name EmployeesController to your Web API project, as shown in Listing 4-3. You can directly copy and paste the Japanese characters into the class file and compile.

   Listing 4-3.  The EmployeesController Class

   using System.Collections.Generic;
   using System.Linq;
   using System.Web.Http;
   using HelloWebApi.Models;
    
   public class EmployeesController : ApiController
   {
       private static IList<Employee> list = new List<Employee>()
       {
           new Employee()
           {
               Id = 12345, FirstName = "John", LastName = ""
           },
                
           new Employee()
           {
               Id = 12346, FirstName = "Jane", LastName = "Public"
           },
    
           new Employee()
           {
               Id = 12347, FirstName = "Joseph", LastName = "Law"
           }
       };
    
       public Employee Get(int id)
       {
           return list.First(e => e.Id == id);
       }
   }

6. Fire up Fiddler and send a GET request from the Composer tab to the URI http://localhost:55778/api/employees/12345. Remember to replace the port 55778 with the actual port that your application runs on.
7. The response returned is shown in Listing 4-4. Some of the headers are removed for brevity.

   Listing 4-4.  Web API Response Showing Default Character Encoding

   HTTP/1.1 200 OK
   Content-Type: application/json; charset= utf-8
   Date: Fri, 29 Mar 2013 03:51:11 GMT
   Content-Length: 87
    
   {"Id":12345,"FirstName":"John","LastName":""}
   

8. ASP.NET Web API has returned the content encoded in UTF-8, which is the first element in the SupportedEncodings collection that we looped through and printed the members in Listing 4-2.
9. Change the request in the Request Headers text box as shown in Listing 4-5 and click Execute.

   Listing 4-5.  Web API Request Asking for UTF-16

   Host: localhost:55778
   Accept-charset: utf-16

10. Web API returns the response shown in Listing 4-6. Some of the headers are removed for brevity. This time, the response is encoded in UTF-16. Because of this, the content-length has increased from 87 to 120.

    Listing 4-6.  Web API Response Encoded in UTF-16

    HTTP/1.1 200 OK
    Content-Type: application/json; charset= utf-16
    Date: Fri, 29 Mar 2013 03:52:20 GMT
    Content-Length: 120
     
    {"Id":12345,"FirstName":"John","LastName":""}
    

11. Change the request in the Request Headers text box as shown in Listing 4-7 and click Execute.

    Listing 4-7.  Web API Request Asking for DBCS Character Encoding of Shift JIS

    Host: localhost:55778
    Accept-charset: shift_jis
    

12. Web API returns the response shown in Listing 4-8. Some of the headers are removed for brevity. Since Shift JIS is not supported out of the box, ASP.NET Web API reverts to the default encoding, which is UTF-8. This is negotiation in action.

    Listing 4-8.  Web API Response When Client Requested Shift JIS

    HTTP/1.1 200 OK
    Content-Type: application/json; charset= utf-8
    Date: Fri, 29 Mar 2013 03:57:55 GMT
    Content-Length: 87
     
    {"Id":12345,"FirstName":"John","LastName":""}
     

4.2 Supporting DBCS Character Encoding (Shift JIS)

In this exercise, you will add support for a double-byte character set (DBCS) such as Shift JIS. The term DBCS refers to a character encoding where each character is encoded in two bytes. DBCS is typically applicable to oriental languages like Japanese, Chinese, Korean, and so on. Shift JIS (shift_JIS) is a character encoding for the Japanese language. Code page 932 is Microsoft’s extension of Shift JIS.

Why bother with DBCS like Shift JIS when Unicode is there? The answer is that there are still legacy systems out there that do not support Unicode. Also, believe it or not, there are database administrators who are not willing to create Unicode databases, and there are still old and outdated IT administration policies that prohibit creation of databases in Unicode to save storage cost, even though storage prices have fallen to such a degree that this cost-saving point becomes moot. But there are still applications out there that do not handle Unicode!

1. Modify the Register method of the WebApiConfig class in the App_Start folder, as shown in Listing 4-9. The new line to be added is shown in bold type.

   Listing 4-9.  Enabling Shift JIS

   using System.Text;
   using System.Web.Http;
    
   public static class WebApiConfig
   {
       public static void Register(HttpConfiguration config)
       {
           config.Routes.MapHttpRoute(
               name: "DefaultApi",
               routeTemplate: "api/{controller}/{id}",
               defaults: new { id = RouteParameter.Optional }
           );
    
           config.Formatters.JsonFormatter
                                   .SupportedEncodings
                                           .Add(Encoding.GetEncoding(932));
    
           foreach (var encoding in config.Formatters.JsonFormatter.SupportedEncodings)
           {
               System.Diagnostics.Trace.WriteLine(encoding.WebName);
           }
       }
   }
   

2. This code adds Shift JIS support to ASP.NET Web API on a per-formatter basis; it adds Shift JIS support only to JsonFormatter. It uses the Encoding.GetEncoding method to get the Encoding object corresponding to the code page of 932, which is Shift JIS.
3. Rebuild the solution in Visual Studio.
4. Retry the previous Shift JIS request. Change the request in the Request Headers text box, as shown in Listing 4-7 earlier, and click Execute. The following are the headers to be copy-pasted, for your easy reference.

   Host: localhost:55778
   Accept-charset: shift_jis
   

5. Web API returns the response shown in Listing 4-10. Some of the headers are removed for brevity. Now, the charset in the response is shown as shift_jis. Also, the content length is only 73 now, even less than we got with UTF-8.

   Listing 4-10.  Web API Response Encoded in Shift JIS

   HTTP/1.1 200 OK
   Content-Type: application/json; charset= shift_jis
   Date: Fri, 29 Mar 2013 04:19:36 GMT
   Content-Length: 73
    
   {"Id":12345,"FirstName":"John","LastName":""}

6. Modify the static list in EmployeesController to update the last name of the employee with ID 12345 from to Human, as shown in Listing 4-11.

   Listing 4-11.  EmployeesController Modified to Remove Japanese Characters

   public class EmployeesController : ApiController
   {
       private static IList<Employee> list = new List<Employee>()
       {
           new Employee()
           {
               Id = 12345, FirstName = "John", LastName = "Human"
           },
                
           new Employee()
           {
               Id = 12346, FirstName = "Jane", LastName = "Public"
           },
    
           new Employee()
           {
               Id = 12347, FirstName = "Joseph", LastName = "Law"
           }
       };
    
       // Rest of the code goes here
   }
    

4.3 Negotiating Content Encoding (Compression)

Content coding is the encoding transformation applied to an entity. It is primarily used to allow a response message to be compressed. The main objective of HTTP compression is to make better use of available bandwidth. Of course, this is achieved with a tradeoff in processing power. The HTTP response message is compressed before it is sent from the server, and the client indicates, in the request, its preference for the compression schema to be used. A client that does not support compression can opt out of it and receive an uncompressed response. The most common compression schemas are gzip and deflate. HTTP/1.1 specifies identity, which is the default encoding to denote the use of no transformation. These values are case-insensitive.

A client sends the compression schema values along with an optional quality factor value in the Accept-Encoding request header. The server (Web API) tries to satisfy the request to the best of its ability. If Web API can successfully encode the content, it indicates the compression schema in the response header Content-Encoding. Based on this, a client can decode the content. The default identity is used only in the request header of Accept-Encoding and not in the response Content-Encoding. Sending identity in Content-Encoding is same as sending nothing. In other words, the response is not encoded.

Table 4-1 shows a few sample Accept-Encoding request headers and the corresponding response details for an ASP.NET Web API that supports gzip and deflate compression schema in that order of preference.

The following exercise demonstrates the steps involved in building a Web API that supports gzip and deflate, and negotiating with the client, as described in the preceding table.

1. You can use the same project that you created with any of the previous exercises or you can create a new ASP.NET MVC 4 project using Web API template. I use the same project from the previous exercise.
2. Create a new class named EncodingSchema, as shown in Listing 4-12. The field supported is a dictionary with a key the same as the supported encoding scheme. Currently, there are only two of them: gzip and deflate. The value is a Func delegate that represents the method for creating and returning the stream object: GZipStream and DeflateStream respectively for gzip and deflate. The corresponding methods are GetGZipStream and GetDeflateStream.

   Listing 4-12.  EncodingSchema (Incomplete)

   using System;
   using System.Collections.Generic;
   using System.IO;
   using System.IO.Compression;
   using System.Linq;
   using System.Net.Http.Headers;
    
   public class EncodingSchema
   {
       private const string IDENTITY = "identity";
    
       private IDictionary<string, Func<Stream, Stream>> supported =
                            new Dictionary<string, Func<Stream, Stream>>
                                              (StringComparer.OrdinalIgnoreCase);
    
       public EncodingSchema()
       {
           supported.Add("gzip", GetGZipStream);
           supported.Add("deflate", GetDeflateStream);
       }
    
       // rest of the class members go here
   }

3. Add the two methods shown in Listing 4-13 to the class.

   Listing 4-13.  Methods to Get the Compression Streams

   public Stream GetGZipStream(Stream stream)
   {
       return new GZipStream(stream, CompressionMode.Compress, true);
   }
    
   public Stream GetDeflateStream(Stream stream)
   {
       return new DeflateStream(stream, CompressionMode.Compress, true);
   }
   

4. Add another method, named GetStreamForSchema, for returning the Func delegate from the dictionary based on the schema passed in. For example, when the schema passed in is gzip, the Func<Stream, Stream> returned by this method corresponds to the GetGZipStream method that we defined in the previous step. See Listing 4-14.

   Listing 4-14.  GetStreamForSchema Method

   private Func<Stream, Stream> GetStreamForSchema(string schema)
   {
       if (supported.ContainsKey(schema))
       {
           ContentEncoding = schema.ToLowerInvariant();
           return supported[schema];
       }
    
       throw new InvalidOperationException(String.Format("Unsupported encoding schema {0}",
                                                                                     schema));
   }

5. Add a property named ContentEncoding and another method named GetEncoder, as shown in Listing 4-15. The ContentEncoding property is set by the GetEncoder method through the private setter. For the other classes, it is a read-only property. This property returns the value to be put into the Content-Encoding response header.

   Listing 4-15.  The ContentEncoding Property and the GetEncoder Method

   public string ContentEncoding { get; private set; }
    
   public Func<Stream, Stream> GetEncoder(
                                   HttpHeaderValueCollection<StringWithQualityHeaderValue> list)
   {
           // The following steps will walk you through
           // completing the implementation of this method
   }

6. Add the code shown in Listing 4-16 to the GetEncoder method. If the incoming list is null or has a count of 0, no processing happens and a null is returned. The incoming list is of type HttpHeaderValueCollection<StringWithQualityHeaderValue>. Each element in this collection consists of the encoding scheme along with the quality value as requested by the client in the Accept-Encoding header. For example, Accept-Encoding: gzip;q=0.8, deflate will be represented by two elements in the collection: the first element with a Value of gzip and a Quality of 0.8 and the second element with a Value of deflate and a Quality of null. Quality is a nullable decimal.

   Listing 4-16.  The GetEncoder Method

   if (list != null && list.Count > 0)
   {
           // More code goes here
   }
    
   // Settle for the default, which is no transformation whatsoever
   return null;
   

7. Add the code in Listing 4-17 to the if block for a list that is not null and has Count > 0. This is the part where negotiation happens, in the following steps. The end result of this process is that the encoding scheme to be used for encoding the response message is chosen.
   • a.   Order the incoming schemes in descending order of quality value. If quality value is absent, treat it as 1.0. Choose only the schemes that have either quality value absent or present and nonzero. Match these schemes against the list of supported schemes and get the first one. If this first scheme is not null, return the corresponding scheme’s transformation function in the form of the Func delegate by calling the GetStreamForSchema method that we saw earlier. This method just returns a new Stream object corresponding to the chosen schema. Since we support only gzip and deflate, this Stream object could be either GZipStream or DeflateStream.
   • b.   If there is no match so far, see if there is a scheme of value * and quality factor of nonzero. If so, the client is willing to accept what the Web API supports. However, a client could specify a few exceptions through q=0 for specific schemes. Leave out those from the supported schemes and choose one as the scheme to use.
   • c.   If there is still no match, try to use identity. For this, check whether the client has specifically refused to accept identity, by using q=0 against it. If so, fail the negotiation by throwing NegotiationFailedException.
   • d.   As the final step, see if the client has refused all schemes through *;q=0 and has not explicitly asked for identity. In that case also, fail the negotiation by throwing NegotiationFailedException. This will send back the response status code of 406 - Not Acceptable.
   • e.   If there is no match and we do not have to throw the NegotiationFailedException so far, just skip content encoding.

     Listing 4-17.  The GetEncoder Method Continuation

     var headerValue = list.OrderByDescending(e => e.Quality ?? 1.0D)
                             .Where(e => !e.Quality.HasValue ||
                                         e.Quality.Value > 0.0D)
                             .FirstOrDefault(e => supported.Keys
                                     .Contains(e.Value, StringComparer.OrdinalIgnoreCase));
      
     // Case 1: We can support what client has asked for
     if (headerValue != null)
         return GetStreamForSchema(headerValue.Value);
      
     // Case 2: Client will accept anything we support except
     // the ones explicitly specified as not preferred by setting q=0
     if (list.Any(e => e.Value == "*" &&
             (!e.Quality.HasValue || e.Quality.Value > 0.0D)))
     {
         var encoding = supported.Keys.Where(se =>
                             !list.Any(e =>
                                         e.Value.Equals(se, StringComparison.OrdinalIgnoreCase) &&
                                             e.Quality.HasValue &&
                                                 e.Quality.Value == 0.0D))
                                                     .FirstOrDefault();
         if (encoding != null)
             return GetStreamForSchema(encoding);
     }
      
     // Case 3: Client specifically refusing identity
     if (list.Any(e => e.Value.Equals(IDENTITY, StringComparison.OrdinalIgnoreCase) &&
             e.Quality.HasValue && e.Quality.Value == 0.0D))
     {
      
         throw new NegotiationFailedException();
     }
      
     // Case 4: Client is not willing to accept any of the encodings
     // we support and is not willing to accept identity
     if (list.Any(e => e.Value == "*" &&
             (e.Quality.HasValue || e.Quality.Value == 0.0D)))
     {
         if (!list.Any(e => e.Value.Equals(IDENTITY, StringComparison.OrdinalIgnoreCase)))
             throw new NegotiationFailedException();
     }
     

8. Create a new Exception class:

   public class NegotiationFailedException : ApplicationException { }.
    

   It does not carry any additional information and just derives from ApplicationException.

9. Create a new class EncodedContent that derives from HttpContent, as shown in Listing 4-18.
   • a.   Accept an object of type HttpContent and the Func delegate in the constructor and store them in class-level fields. In the constructor, loop through the headers of the passed-in HttpContent object and add them to this instance.
   • b.   Override the TryComputeLength method and return false, since the length will not be known at the time method is called.
   • c.   Override the SerializeToStreamAsync method. Invoke the Func delegate and pass the resulting Stream object into the CopyToAsync method of the class-level field of type HttpContent.
   • d.   Note the usage of the await keyword to wait for the execution to return after the previous async call.

     Listing 4-18.  The EncodedContent Class

     using System;
     using System.IO;
     using System.Linq;
     using System.Net;
     using System.Net.Http;
     using System.Threading.Tasks;
      
     public class EncodedContent : HttpContent
     {
         private HttpContent content;
         private Func<Stream, Stream> encoder;
      
         public EncodedContent(HttpContent content, Func<Stream, Stream> encoder)
         {
             if (content != null)
             {
                 this.content = content;
                 this.encoder = encoder;
      
                 content.Headers.ToList().ForEach(x =>
                                 this.Headers.TryAddWithoutValidation(x.Key, x.Value));
             }
         }
      
         protected override bool TryComputeLength(out long length)
         {
             // Length not known at this time
             length = -1;
             return false;
         }
      
         protected async override Task SerializeToStreamAsync(Stream stream,
                                                                      TransportContext context)
         {
             using (content)
             {
                 using (Stream encodedStream = encoder(stream))
                 {
                     await content.CopyToAsync(encodedStream);
                 }
             }
         }
     }

10. Create a new message handler named EncodingHandler, as shown in Listing 4-19. The message handler brings together the other classes we created in this exercise so far. It encodes the response and sets that as the current response content. It also adds the Content-Encoding response header. If NegotiationFailedException is thrown, it stops the processing by sending back a 406 -Not Acceptable status code.

    Listing 4-19.  The EncodingHandler

    using System.Net;
    using System.Net.Http;
    using System.Threading;
    using System.Threading.Tasks;
     
    public class EncodingHandler : DelegatingHandler
    {
        protected override async Task<HttpResponseMessage> SendAsync(
                                         HttpRequestMessage request,
                                                CancellationToken cancellationToken)
        {
            var response = await base.SendAsync(request, cancellationToken);
     
            try
            {
                var schema = new EncodingSchema();
                var encoder = schema.GetEncoder(response.RequestMessage
                                                                  .Headers.AcceptEncoding);
     
                if (encoder != null)
                {
                    response.Content = new EncodedContent(response.Content, encoder);
     
                    // Add Content-Encoding response header
                    response.Content.Headers.ContentEncoding.Add(schema.ContentEncoding);
                }
            }
            catch (NegotiationFailedException)
            {
                return request.CreateResponse(HttpStatusCode.NotAcceptable);
            }
     
            return response;
        }
    }
    

11. Since it is preferable to encode the content as the final step of the ASP.NET Web API pipeline, we use the message handler. Hence, it is important to configure this as the first handler so that the response processing part runs last. See Listing 4-20, where I have added the message handler to the handlers collection in WebApiConfig in the App_Start folder. Since we use the same project as the previous exercises, you see additional lines of code in WebApiConfig, but those lines do not have any bearing on the outcome of this exercise.

    Listing 4-20.  Configuring a Message Handler

    public static class WebApiConfig
    {
        public static void Register(HttpConfiguration config)
        {
            config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );
     
            config.Formatters.JsonFormatter
                                    .SupportedEncodings
                                        .Add(Encoding.GetEncoding(932));
     
            foreach (var encoding in config.Formatters.JsonFormatter.SupportedEncodings)
            {
                System.Diagnostics.Trace.WriteLine(encoding.WebName);
            }
     
            config.MessageHandlers.Add(new EncodingHandler());
            // Other handlers go here
        }
    }
    

12. Rebuild the solution.
13. Make a GET request from Fiddler for http://localhost:55778/api/employees/12345. Use different values in the Accept-Encoding header and see how Web API responds. For example, in Figure 4-1 I used Accept-Encoding: gzip;q=0.8, deflate. Since deflate has the quality factor of 1 (default), it is chosen for encoding, as shown by Fiddler.

    

    Figure 4-1. Fiddler Responding to DEFLATE Encoding

14. Now, make a GET request to http://localhost:55778/api/employees, keeping the Accept-Encoding: gzip;q=0.8, deflate. Note the Content-Length, which is 80. This could be different for you based on what you return from the action method.
15. Make the GET request one more time, the same as in the previous step but do not give the Accept-Encoding header. The Content-Length now is 155, since we have opted out of compression for this request. This is compression or content encoding in action.
16. Let us now see how WebClient handles content coding. Create a console application with a name of TestConsoleApp. The Main method is shown in Listing 4-21. Remember to replace the port 55778 with the actual port that your application runs on.

    Listing 4-21.  WebClient Requesting a Content Encoded Response

    using System;
    using System.Net;
     
    class Program
    {
        static void Main(string[] args)
        {
            string uri = " http://localhost:45379/api/employees/12345 ";
     
            using (WebClient client = new WebClient())
            {
                client.Headers.Add("Accept-Encoding", "gzip, deflate;q=0.8");
                var response = client.DownloadString(uri);
     
                Console.WriteLine(response);
            }
        }
    }
    

17. The preceding code prints some gibberish, as expected. We ask for compressed response but download the response as string without decompressing the bytes.

    

18. To make WebClient work correctly, use the code shown in Listing 4-22. Instead of using WebClient directly, this code subclasses it and overrides the GetWebRequest method to set the AutomaticDecompression property of HttpWebRequest. That will ensure the response is automatically decompressed.

    Listing 4-22.  WebClient Decompressing the Response

    class Program
    {
        static void Main(string[] args)
        {
            string uri = " http://localhost.fiddler:55778/api/employees/12345 ";
     
            using (AutoDecompressionWebClient client = new AutoDecompressionWebClient())
            {
                client.Headers.Add("Accept-Encoding", "gzip, deflate;q=0.8");
                Console.WriteLine(client.DownloadString(uri));
            }
        }
    }
     
    class AutoDecompressionWebClient : WebClient
    {
        protected override WebRequest GetWebRequest(Uri address)
        {
            HttpWebRequest request = base.GetWebRequest(address)
    as HttpWebRequest;
            request.AutomaticDecompression = DecompressionMethods.Deflate
                                                                | DecompressionMethods.GZip;
             
            return request;
        }
    }
     

4.4 Negotiating Language

The Accept-Language request header can be used by clients to indicate the set of preferred languages in the response. For example, Accept-Language: en-us, en-gb;q=0.8, en;q=0.7 indicates that the client prefers American English but when the server cannot support it, can accept British English. When that is also not supported, other types of English are also acceptable. The Accept-Language header is meant to specify the language preferences, but is commonly used to specify locale preferences as well.

Summary

Content negotiation is the process of selecting the best representation for a given response when there are multiple representations available. It is not called format negotiation, because the alternative representations may be of the same media type but use different capabilities of that type, they may be in different languages, and so on. The term negotiation is used because the client indicates its preferences. A client sends a list of options with a quality factor specified against each option, indicating the preference level. It is up to the service, which is Web API in our case, to fulfill the request in the way the client wants, respecting the client preferences. If Web API is not able to fulfill the request the way the client has requested, it can switch to a default or send a 406 - Not Acceptable status code in the response.

Character encoding denotes how the characters—letters, digits, and other symbols—are represented as bits and bytes for storage and communication. The HTTP request header Accept-Charset can be used by a client to indicate how the response message can be encoded. ASP.NET Web API supports UTF-8 and UTF-16 out of the box.

Content coding is the encoding transformation applied to an entity. It is primarily used to allow a response message to be compressed. An HTTP response message is compressed before it is sent from the server, and the clients indicate their preference for the compression schema to be used in the request header Accept-Encoding. A client that does not support compression can opt out of compression and receive an uncompressed response. The most common compression schemas are gzip and deflate. The .NET framework provides classes in the form of GZipStream and DeflateStream to compress and decompress streams.

The Accept-Language request header can be used by clients to indicate the set of preferred languages in the response. The same header can be used to specify locale preferences.