Press "Enter" to skip to content

Building consistent responses in ASP.NET Web Api

vpandzic 0

This is my second part of the article about building consistent Web Api response. First was just high level overview about idea for building consistent web api responses. This article is about building consistent responses in ASP.NET Web Api specifically.

Main idea to implement this in ASP.NET Web Api is to make own message handler. A message handler is a class that receives an HTTP request and return an HTTP response. Message handlers derive from an abstract HttpMessageHandler class. Typically, a series of message handlers are chained together. The first handler receives an HTTP request, does some processing, and gives the request to the next handler. At some point, the response is created and goes back up the chain. This pattern is called delegating handler.

To make custom message handler it is necessary to derive from System.Net.Http.DelegatingHandler and override SendAsync method.

Currently, this custom message handler does nothing more than default message handler. But we will change that to make consistent web api response. For beggining, let’s see how that response model will look like:

Same response model will be returned in case of success and failure. The difference will be in status code, and in the fact that Result property will be null in case of failure, and Errors property will obviosly contain at least one error. In success scenario it will be the other way around: Result property will contain same object, and errors will be empty array. Notice how Result property is of generic type “object” meaning that can contain any structure. First thing that will have to handle is to make ASP.NET Web Api return errors inside Errors property of our ResponsePackage class. By default, JSON that was returned from Web Api when error happens looks something like this:

To be complete, let’s write controller that returned this error:

This is UpdateModel class:

As you can see, by default ASP.NET Web Api reads data annotations on model class, and creates aproppriate  response. However, this is not what web want but we will try to get data from ModelState that ASP.NET Web Api created and put them in our own response.

Let’s create method BuildConsistentWebApiResponse  that will do all processing. Most code inside that method will be about making ModelState conform our shape of the response object.

First thing we have to do inside BuildConsistentWebApiResponse  method is to check if we have response body and if it is response code different than 200. If all conditions are met we can try to retrieve errors from ModelState  property of the HttpError object.

PopulateErrorsArrayFromModelStateProperty  method look like this:

Inside that method we are deserializing response content, reading errors inside ModelState property and putting them inside our modelStateErrors list.

Sometimes, there will not be ModelState  property.  In that case, PopulateErrorsArrayFromValuesProperty  method will be called.

Last thing we have to do inside BuildConsistentWebApi  response method is to create response object and add back response headers:

To put this message handler in work you will have to register it inside register method of your web api.

Result of this is that you will have consistent responses across your Web Api making implementation of it much more easier and enjoyable. All things from ASP.NET Web Api like data annotations still work and that is great thing about message handlers and ASP.NET Web Api. You can custom tailor it to your needs while other things you didn’t touch still continue to work.

 

    Leave a Reply

    Your email address will not be published. Required fields are marked *