One of the key aspects of how the web works today is content negotiation. The idea of content negotiation is based on the fact that a single resource can have multiple representations, so user agents (or clients) and servers can work together to chose one of them.
The http specification defines several “Accept”
headers that a client can use to negotiate content with a server, and among all those, there is one for restricting the set of natural languages that are preferred as a response to a request, “Accept-Language”. For example, a client can specify “es” in this header for specifying that he prefers to receive the content in spanish or “en” in english.
However, there are certain scenarios where the “Accept-Language” header is just not enough, and you might want to have a way to pass the “accepted” language as part of the resource url as an extension. For example, http://localhost/ProductCatalog/Products/1.es” returns all the descriptions for the product with id “1” in spanish. This is useful for scenarios in which you want to embed the link somewhere, such a document, an
email or a page.
Supporting both scenarios, the header and the url extension, is really simple in the new WCF programming model. You only need to provide a processor implementation for any of them.
Let’s say I have a resource implementation as part of a product catalog I want to expose with the WCF web apis.
[ServiceContract][Export]public class ProductResource{ IProductRepository repository; [ImportingConstructor] public ProductResource(IProductRepository repository) { this.repository = repository; } [WebGet(UriTemplate = "{id}")] public Product Get(string id, HttpResponseMessage response) { var product = repository.GetById(int.Parse(id)); if (product == null) { response.StatusCode = HttpStatusCode.NotFound; response.Content = new StringContent(Messages.OrderNotFound); } return product; }}
The Get method implementation in this resource assumes the desired culture will be attached to the current thread (Thread.CurrentThread.Culture). Another option is to pass the desired culture as an additional argument in the method, so my processor implementation will handle both options. This method is also using an auto-generated class for handling string resources, Messages, which is available in the different cultures that the service implementation supports. For example,
Messages.resx contains “OrderNotFound”: “Order Not Found”
Messages.es.resx contains “OrderNotFound”: “No se encontro orden”
The processor implementation bellow tackles the first scenario, in which the desired language is passed as part of the “Accept-Language” header.
public class CultureProcessor : Processor<HttpRequestMessage, CultureInfo>{ string defaultLanguage = null; public CultureProcessor(string defaultLanguage = "en") { this.defaultLanguage = defaultLanguage; this.InArguments[0].Name = HttpPipelineFormatter.ArgumentHttpRequestMessage; this.OutArguments[0].Name = "culture"; } public override ProcessorResult<CultureInfo> OnExecute(HttpRequestMessage request) { CultureInfo culture = null; if (request.
Headers.AcceptLanguage.Count > 0) { var language = request.
Headers.AcceptLanguage.First().Value; culture = new CultureInfo(language); } else { culture = new CultureInfo(defaultLanguage); } Thread.CurrentThread.CurrentCulture = culture; Messages.Culture = culture; return new ProcessorResult<CultureInfo> { Output = culture }; }}
As you can see, the processor initializes a new CultureInfo instance with the value provided in the “Accept-Language” header, and set that instance to the current thread and the auto-generated resource class with all the messages. In addition, the CultureInfo instance is returned as an output argument called “culture”, making possible to receive that argument in any method implementation
The following code shows the implementation of the processor for handling languages as url extensions.
public class CultureExtensionProcessor : Processor<HttpRequestMessage, Uri>{ public CultureExtensionProcessor() { this.OutArguments[0].Name = HttpPipelineFormatter.ArgumentUri; } public override ProcessorResult<Uri> OnExecute(HttpRequestMessage httpRequestMessage) { var requestUri = httpRequestMessage.RequestUri.OriginalString; var extensionPosition = requestUri.LastIndexOf("."); if (extensionPosition > -1) { var extension = requestUri.Substring(extensionPosition + 1); var query = httpRequestMessage.RequestUri.Query; requestUri = string.Format("{0}?{1}", requestUri.Substring(0, extensionPosition), query); ; var uri = new Uri(requestUri); httpRequestMessage.
Headers.AcceptLanguage.Clear(); httpRequestMessage.
Headers.AcceptLanguage.Add(new StringWithQualityHeaderValue(extension)); var result = new ProcessorResult<Uri>(); result.Output = uri; return result; } return new ProcessorResult<Uri>(); }}
The last step is to inject both processors as part of the service configuration as it is shown bellow,
public void RegisterRequestProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode){ processors.Insert(0, new CultureExtensionProcessor()); processors.Add(new CultureProcessor());}
Once you configured the two processors in the pipeline, your service will start speaking different languages :).
Note: Url extensions don’t seem to be working in the current bits when you are using Url extensions in a base address. As far as I could see, ASP.NET intercepts the request first and tries to route the request to a registered ASP.NET Http Handler with that extension. For example, “http://localhost/ProductCatalog/products.es” does not work, but “http://localhost/ProductCatalog/products/1.es” does.
