Tag: Web API

Use custom content-type header in WebAPI or MVC.

The content-type header of the response is affected by the accept header of the request. This is not very obvious at first.

So when you register a custom media type to the JsonFormatter or XmlFormatter, the content-type header will not be changed depending on the type of the response object. Rather it matches the accept header in the request.

If the accept header in the request is not accepted, then the services will default to application/json or application/xml.

Example: let’s say you have a service model called Student, a custom media type “application/mycompany.com+json”, and a web service endpoint that returns a student by ID.

If you just use the browser to make a request to this endpoint, the content-type header in the response will likely be set to “application/json” or “application/xml” depending on your preferred setting and browser.

However if you set the accept header in the request to “application/mycompany.com+json”, the content-type type response header will be set to the same type.

There is no mapping between the types and the service model from the backend side.

Firefox requests for XML format when performing a GET to Web API

Today while testing the Ext JS application I was writing on various browsers, something strange happened. The app works on IE and Chrome, while on Firefox it breaks.

It turns out if not configured correctly WebAPI will return data depending on the Accept HTTP header sent by browsers, and different browsers sent different HTTP Accept header.

More details in the SO answer: http://stackoverflow.com/a/31934984

Firefox prefers XML, so Web API try to serialize data in XML format to return to Firefox.

IE and Chrome doesn’t prefer one over other, so Web API chooses Json.

I solved this issue in Firefox by configuring the web api to always return JSON by adding the following line to WebApiConfig.cs

config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new MediaTypeHeaderValue(“text/html”));

Using Ext JS proxy ajax writer

The default behaviour of Ext JS proxy ajax writer seems to be to always use POST. Whenever trying to create/update/delete a record, a JSON object will be sent to the server in the request payload through POST.

It might be possible to configure the proxy and writer to use other HTTP methods like PUT and DELETE, but I haven’t seen any documentation on this yet.

The Id field is always included. So there are 3 cases

  • When the request is to create/update the record, the fields with data will be included. Example: {“Id”:1, “Name”:”Tom”}. Using the Id the server can determine whether it’s a update or create request if a record with same Id already exists.
  • When deleting a record, only the Id is included in the JSON object. Example: {“Id”: 1}. The server can determine that it’s a delete request by checking the number of properties the JSON object has.

If the server is written in ASP.NET Web API, it’s important to read the request body and process it manually instead of using a parameter in the method and let the framework do the deserialization automatically, because then it will not be possible to count the number of properties the object original has, the deserialized object has all properties with default values for missing ones.

Consume Web API response in SSRS

Follow the article: http://jaliyaudagedara.blogspot.sg/2015/10/using-aspnet-web-api-as-data-source-for.html

Need to configure the web api service to always return XML data. When configuring the data source, add ?type=xml at the end of the URL.

Note: for SSRS/Report Builder to retrieve the fields, don’t use blank query string, use the following:

<Query>

</Query>

Cannot bind multiple parameters in Web Api, cannot bind Json parameter

Simple, Web Api 1 doesn’t support multiple parameters.

Also, make sure the route config are correct so that the controller and action can be reached.

To bind Json parameter, use Content-Type: application/json in the request header, make sure the json object is the root object and the model to load from the server user properties instead of fields.