Web API Exception Handling And Versioning Concepts

In this blog, you will learn about Web API exception handling and versioning concepts.

In this blog, we are going to learn about Web API Exception Handling and Versioning concepts. In interviews, many people are asked about Web API exception handling and version handling. Nowadays, both of these concepts have become common questions. Hope my blog will be helpful.

 

So, let us start.

 

Exception handling

 

First, we need to create one Web API solution. If you are a beginner, please refer to the below blog for creating a Web API solution.

• WEB API SOLUTION CREATION

After creating a Web API solution, you will get a default Home Controller and the Values API Controller.

 

Let’s first run the application and call "get a request" through postman. Let's call the Values Controller. Please check the below figure. This is the normal flow of execution and we are getting a proper result.

 

 

Now, let’s make a change in the Get method. Here, I am going to throw an exception. Please check the below figure.

 

NotImplementedException means it initializes a new instance of the System.NotImplementedException class with a specified error message.

 

 

After adding the throw new NotImplementedException(""); statement, please run your solution and call the values controller api/values method. As we know, it throws an exception. Please check the below figure.

 

 

Avoiding the above situation, we need to handle the exception globally.

 

Please check the below figure. In my solution, I have created one folder and named it as "CustomHandler". Inside the folder, I have added one class named "GlobalExceptionHandler".

 

 

For handling the exception globally, our GlobalExceptionHandler class is inheriting the properties of ExceptionHandler.

 

Implementation of the GlobalExceptionHandler class is shown below.

using System.Net;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;
using System.Web.Http;
using System.Web.Http.ExceptionHandling;
namespace WebApi_CustomeExceptoin_Verson.CustomHandler {
    public class GlobalExceptionHandler: ExceptionHandler {
        public override void Handle(ExceptionHandlerContext context) {
            var result = new HttpResponseMessage(HttpStatusCode.InternalServerError) {
                Content = new StringContent("Internal Server Error Occurred"),
                    ReasonPhrase = "Custom Exception"
            };
            context.Result = new ErrorMessageResult(context.Request, result);
        }
        public class ErrorMessageResult: IHttpActionResult {
            private HttpRequestMessage _request;
            private readonly HttpResponseMessage _httpResponseMessage;
            public ErrorMessageResult(HttpRequestMessage request, HttpResponseMessage httpResponseMessage) {
                _request = request;
                _httpResponseMessage = httpResponseMessage;
            }
            public Task < HttpResponseMessage > ExecuteAsync(CancellationToken cancellationToken) {
                return Task.FromResult(_httpResponseMessage);
            }
        }
    }
}

In the above code, you can observe that we have one more class - ErrorMessageResult and inheriting the IHttpActionResult interface.

 

This class will have a Parameterized Constructor which takes 2 parameters,

1. HttpRequestMessage
2. HttpResponseMessage

We are going to assign this HttpResponseMessage to “context.Result”.

 

After handling the exception, next, we need to register this handler.

 

Now, we are going to register “GlobalExceptionHandler” in WebApiConfig class, such that any Web API exception can be handled globally. Please check the below figure. 

 

 

After following the above steps, call the default Values Get method API through postman.

 

Please find the below figure. After throwing an exception, now we display a proper error message, not error stack trace to consumers. The below figure is expressing Get() method throwing exception. 

 

 

But now we implemented an exception handling mechanism so we won't get any error stack trace. Instead of this, we get our custom message. Please observe the below figure.

 

 

The conclusion is after throwing an exception. Now, we display a proper error message, not error stack trace, to the consumers.

API Versioning

 

The most important part of web apps is based on customer requirements we use to change rapidly. If we made some changes to API's those API's are consuming by customer's at the production environment will be breaking the application.solution for this is API Versioning.

 

Let's implement API Versioning, please use the same web API solution, we can implement the API versioning in the same solution. Please go to manage NuGet package manager under the browse tab and search for the below NuGet package,

 

Microsoft.AspNet.WebApi.Versioning

 

Please find the below figure.

 

 

After installing NuGet Package next, we are going to Register AddApiVersioning method in WebApiConfig.cs file.

 

The ApiVersioningOptions class allows you to configure, customize, and extend the default behaviors when you add an API versioning to your application.

 

The ApiVersioningOptions class has the following configuration settings,

1. ApiVersionReader
2. ApiVersionSelector
3. DefaultApiVersion
4. AssumeDefaultVersionWhenUnspecified
5. ReportApiVersions
6. Conventions
7. ErrorResponses
8. RouteConstraintName

I have referred from the below URL so please go through for more understanding. Here my motto is demonstrating programmatically, so I am not explaining more theory.

 

API Versioning Concepts

 

Please register the below code at WebApiConfig class file.

config.AddApiVersioning(o =>
{
   o.ReportApiVersions = true;
   o.AssumeDefaultVersionWhenUnspecified = true;
   o.DefaultApiVersion = new ApiVersion(2, 0);
   o.ApiVersionReader = new HeaderApiVersionReader("version");
   o.ApiVersionSelector = new CurrentImplementationApiVersionSelector(o);
   }
);

Please check the below figure.

 

 

Now, we implemented the API Versioning concept, so let's test it. Please add another API controller with the name “Values2Controller”.

 

After adding the Values2 to the API controller, next, we are going to add Route Attributes to both API controllers,  the old one and the new one. Please check the below figure.

 

 

Now to call the API, we need to pass an API version from the header and the name of the header is “version”.

 

We are going to pass the header name “version” and value as 1.0 to the calling values controller.

 

Please check the below figure.

 

 

After completing with calling version 1.0 values API, next, in the same way, we are going to call values2 API with version 2.0 header.

 

We are going to pass the header name “version” and value as 2.0 to the calling Values2 controller. Please find the below figure.

 

 

SUMMARY

 

We covered practically.

• Exception Handling 
• API Versioning.

Please download the code from the below URL.

• Download