Introduction
This article of the series “Web API with ASP.NET Core” will focus on topics like serializer strings and content negotiation. We learned how to deal with HTTP Status Codes and return sub resources in ASP.NET Core in last article and paused at Serializer Settings. We’ll continue to explore the importance of status codes and practical examples as well. We’ll also explore resource creation and returning the child resources as well in this article. We can use the same source code as we got at the completion of last article of the series.
RoadMap
We’ll follow a roadmap to learn and cover all the aspects of ASP.NET Core in details. Following is the roadmap or list of articles that will cover the entire series.
- Create API with ASP.Net Core (Day 1): Getting Started and ASP.NET Core Request Pipeline
- Create API with ASP.Net Core (Day 2): Create an API and return resources in ASP.NET Core
- Create API with ASP.Net Core (Day 3): Working with HTTP Status Codes and returning sub resources in ASP.NET Core API
- Create API with ASP.Net Core (Day 4): Working with Serializer Settings and Content Negotiation in ASP.NET Core API
- Create API with ASP.Net Core (Day 5): Understanding Resources in ASP.NET CORE API
- Create API with ASP.Net Core (Day 6): Inversion of Control and Dependency Injection in ASP.NET CORE API
- Create API with ASP.Net Core (Day 7): Getting Started with Entity Framework Core
- Create API with ASP.Net Core (Day 8): Entity Framework Core in ASP.NET CORE API
Serializer Settings in ASP.NET Core API
By default, ASP.NET Core uses JSON for serialization and de-serialization, but the best thing is that we can also configure this in our code. If we open the source code we covered in last article, we used ConfigureServices method in the startup class to configure the services use be the container, in the similar way we can configure for MVC.
We can add JSON options to the added MVC service.

Since the AddJsonOptions method expects an action, we supply a lambda expression there as options parameter through which we can easily access the serializer settings as shown in above image. We fetch the contract resolver as we’ll override the default settings of naming strategy. The line var resolver = opt.SerializerSettings.ContractResolver as DefaultContractResolver; takes out the contract resolver and cast ot to the default contract resolver, we can now override its NamingStrategy property and mark it to null.
- public void ConfigureServices(IServiceCollection services)
- {
- services.AddMvc().AddJsonOptions(opt =>
- {
- if (opt.SerializerSettings.ContractResolver != null)
- {
- var resolver = opt.SerializerSettings.ContractResolver as DefaultContractResolver;
- resolver.NamingStrategy = null;
- }
- });
- }
Now, let’s test this with Postman. In the last request, we got the json properties in lower case letters as shown below,

Now, run the application and make a request for the same API from postman as consumer.

Now, we get the JSON properties in capital letters i.e. overridden by our implementation. This implementation is on a need basis or based on the kind of JSON the consumer wants. Here comes the concept of content negotiation where response is sent based on consumers request parameters.
Content Negotiation and Formatters in ASP.NET Core API
Content negotiation is one of the important concepts when we develop an API. This enables an API to select best representation for a desired response when there are more than one representations available. Suppose we build an API for multiple consumers and clients we are not sure that whether all the clients would be able to consume the default representation that an API sends in the form JSON. Some consumers may expect XML as a response or any other format, in that case it would be hard for the consumers to understand and work with JSON instead of a XML.
There is always an option to the consumer to send a request for a specific format by specifying the requested media type in the Accept header. For e.g. if in the accept header, the requested format is XML, the API should send the response in XML format and if it is JSON, the API should send the response in JSON format. If there is no header specified, then API can take liberty to send the response in the default format that it has for e.g. JSON in our case. ASP.NET Core also supports this functionality via output formatters. Output formatter, as the name suggests mostly deals with the output. The consumer in that case can request any specific type of output that it wants by setting the accept header to request media type such as Application/JSON or Application/XML.








Mike BradleyPosted Nov 13, 2018, 4:55 AM
.... still waiting for next parts think i'll go elsewhere
Purnima SoorajPosted Sep 5, 2018, 6:49 AM
Very nice article, but waiting for page 5
Naresh SinghalPosted Jan 12, 2018, 7:15 AM
Nicely explained .......liked it
Donald MogalePosted Jun 23, 2017, 2:35 PM
Hi Akhil I have been following your article and I must say that I really enjoying it, but the day 5 and so on are not been posted. When are you going to post it?