Tom DuPont .NET

One of my favorite quotes is "there is nothing as embarrassing as yesterday's code." I blogged about a paged list class a while back, but I no longer like that implementation...so here is a new one that includes WebAPI serialization support!

...but why is this useful?

You can use the simple IPagedList interface to pass paged data around all of your application, and then any object returned from your WebAPI that implements IPagedList will be automatically serialized for you. This allows you to create very consistent APIs that support paging.

IPagedList Interfaces

public interface IPagedList

{

 int PageIndex { get; }

 int PageSize { get; }

 int TotalCount { get; }

 IList List { get; }

}

public interface IPagedList<T> : IPagedList

{

 new IList<T> List { get; }

}

Returning the appropriate HTTP Response Codes back from your web server is a very important best practice. Fortunately for .NET developers, Web API makes it very easy to use Exception Filters to return the appropriate response codes from your exceptions.

By implementing a custom ExceptionFilterAttribute you can generically create and return HttpResponseMessages for unhandled exceptions based on type. This is great in that you do not have to wrap all of your controller actions in try catch blocks to handle exceptions from other application layers.

Sample Controller

public class ValuesController : ApiController

{

 public string Get(int id)

 {

 switch (id)

 {

 case 1:

 throw new KeyNotFoundException("Hello World");

 case 2:

 throw new ArgumentException("Goodnight Moon");

 default:

 return "value";

 }

 }

}

When you using Web API, would you like to always return a 400 (bad request) response whenever the model state is invalid? It is easy, just add the following filter attribute to your global list:

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, 

 AllowMultiple = false, 

 Inherited = true)]

public class InvalidModelStateFilterAttribute : ActionFilterAttribute

{

 public override void OnActionExecuting(HttpActionContext actionContext)

 {

 if (!actionContext.ModelState.IsValid)

 {

 actionContext.Response = actionContext.Request.CreateErrorResponse(

 HttpStatusCode.BadRequest, 

 actionContext.ModelState);

 }

 }

}

Enjoy,
Tom

In my last post I talked about using both Basic and Digest authentication with WebAPI, but not at the same time. So what do you do when you want to used mixed authentication with both?

In principal you can support both Basic and Digest authentication at the same time, but your server has to issue the 401 challenge with Digest. This is because basic requires no token or server information to authenticate, where as digest requires a nonce from the server.

I have updated Rick's Basic authentication and Badri's Digest authentication implementation to work together as a pair of AuthorizationFilterAttributes. Here is the source:

• DigestAuthDemo on GitHub

public static class WebApiConfig

{

 public static void Register(HttpConfiguration config)

 {

 config.Filters.Add(new BasicAuthorizationFilterAttribute(false));

 config.Filters.Add(new DigestAuthorizationFilterAttribute());

 config.MapHttpAttributeRoutes();

 config.Routes.MapHttpRoute(

 "DefaultApi",

 "{controller}/{id}",

 new { controller = "data", id = RouteParameter.Optional }

 );

 }

}

Enjoy,
Tom

Google Chrome supports four HTTP authentication types:

1. Basic
2. Digest
3. NTLM
4. Negotiate

ASP.NET WebAPI has AuthorizationFilterAttributes which can be used to implement both Authentication and Authorization for your APIs. If you want to use Basic or Digest authentication, there are already several open source implementations available to help you out!

• Rick Strahl - WebAPI Basic Authentication Authorization Filter
• Badri - Digest Authentication with ASP.NET Web API

Do you need to used mixed authentication and support both Basic and Digest?
If so, be sure to check out my next blog post...

Enjoy,
Tom